(I've been thinking about this idea a bit -- if this is not the right project, please move this issue.)
As background, in a previous day job, I worked extensively with a tracking system managing bills and resolutions as they moved through a state legislature's workflow. Bills were introduced, debated, amended, etc., etc., and were -- somewhat rarely -- enacted. Multiple bills in the system during any one session could introduce different text changes within the same section of statute, so as each bill was introduced, a list of the section and code references of each paragraph changed by each introduction/amendment was stored in the database along with the changes. Since each paragraph of text is addressable through a highly controlled numbering system, the system could be queried to determine exactly what bills modified a particular section of code, and where those bills were in the legislative process. Obviously, if a bill making changes to code section 27-15-238(1)(a)(iii), for instance, passed, then other bills referencing that same section would have to be reconciled before passage, so that the changes by a bill passed early in a session were not overwritten by later enactments.
This, as a type of version control, has some parallels to Drupal's code management system. I'm particularly interested in the idea that the testing server (or some other system) might be able to -- as it went about reviewing patches automatically -- populate a database table with module names and line numbers of the (source) code being impacted by each patch. Given a table representing this information for, say, all patches needing work or needing review, it might be possible to create an advanced search option returning all patches in the queue impacting a specific code area, given a module name and line number (and some number representing the lines before and after).
Surely this would have reduce code duplication in the queue, by pinpointing companion, conflicting or duplicate patches. The same data could possibly be used to automatically pinpoint patches requiring a known reroll (because another patch touching the same code areas was just committed). And, such a system may return some metrics of interest -- the system could track the number of patches impacting FAPI, for instance. Or, provide for every patch a simple table showing the files touched by the patch, with the number of lines added/deleted/modifed for each file.
Thoughts?
Comments
Comment #1
keith.smith commentedI still think this would be a cool addition, but I've even less certain now that this is the right project for the request. I'm "won't fix"ing it until I can contribute some code in this regard myself.