
Description
The PatchInfo module allows you to add information about patches to a module's .info.yml file. It will show the information prominently in the update report and on the update manager form. See the documentation on the project page or in the README file on how to set this up for Drupal 7 or Drupal 8.
You can also exclude a module from the update check, by specifying the machine readable name of the module on the (extended) update manager settings form.
The module comes with basic Drush integration, i.e. a command to list patches on the whole system or for a specific module in several different formats.
We have used this successfully on numerous Drupal 7 sites to track patches in contributed modules and core. The idea is to have a simple way for developers to add information about patches and have these available prominently in the key places you would check before doing core or module updates. It has served us well over the years and I think it might be useful for other people in the community, too. I just finished the port to Drupal 8, so it might not be as stable as the D7 version, although I did test thoroughly.
Similar projects and how they are different
- Patch Manager: Comprehensive solution to manage patches via UI, may have security implications, if used on production sites (per project page of module).
- Drush Make files: Powerful way to build a whole site from a text file, allows you to manage and apply your patches on the way.
Projet page
https://www.drupal.org/sandbox/feyp/2556153
git clone
git clone --branch 8.x-1.x http://git.drupal.org/sandbox/feyp/2556153.git patchinfo
Reviews of other projects
I will add more reviews here as they are done.
Comments
Comment #2
PA robot commentedWe are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #3
feyp commentedAdded review of custom_email_temaplte.
Comment #4
feyp commentedAdded review of agegate.
Comment #5
feyp commentedAdded review of sidecomments_now and review bonus tag, since it is the 3rd review.
Comment #6
developerchris commentedDisclaimer: I am new to reviewing modules so please bear with my mistakes.
I am interested in what you are trying to achieve here do you envisage an automated process to insert issue patches into .info and .info.yml files?
You say you have been using this system yourself for some time. I am curious if no-one else is using the system how are you able to use it?
Please Note: I have not attempted to review the [D8] Code as I have no experience in [D8]
Manual Review [D7]
Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
Yes: Does not cause module duplication and/or fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
Yes: Follows the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes: Meets the security requirements.
Comment #7
joachim commentedPlease compare with https://www.drupal.org/project/patch_status.
It looks like these are rather similar.
Comment #8
klausimanual review:
Otherwise looks good to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Assigning to stBorchert as he might have time to take a final look at this.
Comment #9
joachim commentedLooks like this duplicates https://www.drupal.org/project/patch_status.
Comment #10
klausiDuplication is bad but not an application blocker, anything else that you found or should this stay RTBC?
Comment #11
feyp commentedHi everyone, sorry for not following up sooner.
@DeveloperChris: Thank you for your review! Let me address your question:
You could certainly create a script, that will automatically update the info file once you apply a patch. But that's not how we use the module. Originally, we documented all patches we applied to a system outside of Drupal (i.e. in a wiki). Every time a patch was applied, a developer would hopefully remember to log in to that wiki and update the documentation. Once there was an update for a system, we would check the wiki first. This was quite a little bit of overhead and sometimes, people would forget to update or check the wiki. So we built this module. The idea was to make it as quick as possible for a developer to document patches. Since you're already in the module folder on the command line anyway, when you apply a patch, it isn't that much of a hassle to quickly edit the info file along the way. Once the patch is added by a developer, it will also be added to version control and deployed to other systems. Less overhead for the developer and for our update team.
@joachim: Thanks for pointing this out! Obviously, I wasn't aware of patch_status when I posted the application. I have looked at the module and they are indeed quite similar, although there are some differences. As far as I can see, apart from the different approach for tracking patches (patch files on the file system vs. info file), the most important differences are:
If I'm wrong on any of this, feel free to correct me ;). It seems that the maintainer is currently in the process of creating a pluggable patch detection system. Once that is finished, I might indeed extend that module so that it works for our use case.
I was actually in the process of preparing another module for review, because I was, like you, under the impression, that this might be a blocker for the application. But then klausi beat me to it with his review ;). Actually, I don't care that much about the module, but I'd like to be able to publish some of our modules on drupal.org, so that we might give a little bit back to the community. At the time I opened the application, I thought that patchinfo would be a good fit as I wasn't aware of patch_status. Since klausi and others have kindly invested their time into a review and it seems like we are almost finished now, I think it makes sense to continue the application despite the similarity to patch_status at this time and not start all over again with another module. Again, if anyone has different views on this, please let me know.
@klausi: Thank you very much for your review! I have made the changes you suggested and also added a section about patch_status to the project page.
Comment #12
feyp commentedComment #13
feyp commentedAdded review of views_exposed_filters_summary.
Comment #14
klausino other objections for more than a week, so ...
Thanks for your contribution, Patrick!
I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.
Comment #15
feyp commentedThank you @klausi!
Comment #17
avpaderno