Bug-enhancement patch Workflow
Hi All, See http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow What should we add to this page about the new Pushed to Master / Pushed to Stable status? How can we prevent that further development on a report (followups etc.) interferes with the process of selecting patches for the maintenance branch? Example: If I have a new followup 2 after patch 1 has been pushed to master, I would like to change status directly to Needs Signoff for patch 2. (But in the meantime Chris N may select patch 1 for maintenance. How? ) Any input is welcome, especially from Chris N here, I suppose.. Marcel
2012/1/18 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>
How can we prevent that further development on a report (followups etc.) interferes with the process of selecting patches for the maintenance branch?
Example: If I have a new followup 2 after patch 1 has been pushed to master, I would like to change status directly to Needs Signoff for patch 2. (But in the meantime Chris N may select patch 1 for maintenance. How? )
Good question. This ties in with another "problem:" that of filing bugs against an enhancement but tagging the bugs as "bugs" rather than "ehn." I wonder if the consistent use of "dependencies" would help in both cases. For example: Case #1: Follow-up patches submitted after pushing to the maintenance branch A new bug is opened for the followup and linked back to the original bug via dependency. Case #2: A bug is filed which applies to a previous enh. The new bug is linked to the enh bug via dependency. These relationships could then be tracked via reports. Make sense? Kind Regards, Chris
participants (2)
-
Chris Nighswonger -
Marcel de Rooy