I'm at a code sprint with members of the Drupal community today, and we're looking for tasks to work on. The agency company I work for manages Drupal sites for a number of clients, and across those sites we might apply patches for the same issues to various projects.
Patches are applied using cweagans/composer-patches and defined per-project using an entry in a composer patches file.
By scanning these files and looking at the related issues, we can get a high-level view of the patches in play, and start to see some interesting things.
My goal for this is to build a Composer plugin (xurizaemon/patchwatch) which can be used as a command from the project's CI, but for today (and mostly due to network issues while travelling) I shot for a quick and dirty PHP script which gave me some serviceable output.
Here's some excerpted and redacted output, to show what we can see afterwards. This is a pretty crude PoC.
And here's the quick script, somewhat munged to hopefully share my rough initial script in a single executable .php. The repository for this project will be https://gitlab.com/xurizaemon/patchwatch
(I haven't embedded the output and script here because I apparently haven't sorted out code embeds on my own blog yet ... sorry!)
The interesting things we can start to see from the output above are:
- Some issues or patches are indeed common to multiple projects, and good candidates to focus on to reduce patch debt!
- Some projects have diverged patches, which points to a maintenance task for those sites. (They may not have matching versions of core, or the differing patches may be correct - but it's worth checking.)
- I included issue status somewhat on a whim, but this turned out really interesting. We see:
- Patches for issues marked "Closed (fixed)", which suggests to check if there's an option to update the component and drop the patch.
- Patches for issues marked "Closed (won't fix)", which suggests that we should review our own use of the patch (and then perhaps revisit our issue communication). This may point to a future conflict between our project with patch, and the module's development direction.
- Patches for issues marked "Closed (can't reproduce)", where we can probably contribute by supplying instructions to reproduce (because we definitely recorded why we introduced this patch, right ...).
Next steps are:
- Consider patching for other projects, eg I recently learned of Node's
patch-packagefrom the Mahara project ... - Implement this suitably for CI, possibly as a Composer plugin (with close integration to
cweagans/composer-patches), or possibly with capacity to consider other build/patch solutions and sources (this version is Drupal-specific and ignores patches to components which don't have adrupal/prefix). - Integrate with systems for managing internal knowledge of which patches are significant to our organisation, so we have visibility for our team to identify issues of interest and can reduce duplicated effort
- Consider whether this tool could be generally useful to capture metrics of patch consumption eg for Drupal.org
- Consider whether the output of this tool is indicating opportunity for us to contribute in other ways, eg by funding the maintainers of modules which we have lots of patches for, or by stepping up to maintain ourselves, ... or reconsidering use of modules which aren't getting patches landed.
Something which might be interesting - if Drupal.org wanted to surface it - would be the download stats / popularity of patch URLs. This might indicate patches which are "popular" and being applied by lots of sites, and good candidates for review.
If this looks useful, or you know of a similar approach to this which I don't or are interested to explore further - get in touch! I'd love to hear from you.
Update: progress report here