On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls <ian.walls@bywatersolutions.com> wrote:

So, to summarize, you're looking for a status that can be set to you know which of the Patches Pushed need to be applied to the previous release?

Correct.

There is currently no facility for specifying multiple releases that a bug applies to. We'd have to create a custom field. The difficulty would come with making use of it. For my part, I only test bugs on master, because I only work on master. Verifying the bug in previous releases doubles or triples the work (depending on how many previous releases I'm supporting). That makes filing the bug report much less sustainable a practice, from a workflow point of view.

The fundamental problem is differentiation between bug fixes for existing features versus bug fixes for enhancements applied either to the current dev cycle or master (they seem the same from my POV).

During the 3.6.0 release cycle, we attempted to maintain the distinction between bug fixes and enhancements by this topic branch nominclature:

'new/bug_X' for bug fixes meant to apply to the current dev branch/master and to the current stable branch

'new/enh/bug_Y' for enhancements meant to apply only to the current dev branch/master.

As we moved forward and the 'new/enh/bug_Y' branch was merged with the current dev branch/master, folks begin filing bug reports for bugs in 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were practically disassociated with 'new/enh/bug_Y' both by a different topic branch designation and a different, unassociated bug number, it became quite difficult to decide what should or should not be backported. (Other problems were caused by this as well, but those will be resolved if we can arrive at a solution for this one.)

I would think that anything that gets applied to master would be a candidate for inclusion in the stable release branch. It would be the job of the RM to determine a) if the bug applies, b) if the patch applies and c) if it's too big a new feature to include in stable. Given the quantity of code produced in a release cycle, I can see this being a massive job.

Perhaps we have not clearly established the job of the RMaint then.

You may recall that when I took up the 3.2.x RMaint job, I specified that the burden of ensuring clean application of a given patch to the current stable branch is the job of the submitter rather than the RMaint. This was agreed to by silent consent. [1] I have followed this policy throughout the 3.4.x RMaint cycle as well.

Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* b) does not apply cleanly to the current stable branch, I post a request to the submitter to rebase and reformat the patch to apply over the current stable branch *if it should.* This places the burden of determining if the patch should, indeed, be backported on the author. (Which is where it should be IMHO. ie. When I mark a bug as assigned to me, I accept the responsibility of ensuring I fix it in all currently supported releases as well as master. Otherwise, I have not truly fixed the bug.)

If this is not what works the best for the majority if the development community, then we need to come up with a work flow which best fits and implement it. Any significant work flow alterations will require more bodies to help with the RMaint process. Based on the response to the call for RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty hard time coming up with the more bodies. ;-)

That said, It seems much simpler to me to just add/modify a field in BZ to allow the author of a given bugfix to indicate which branches the fix should apply to. If the fix needs to be reformatted to apply over multiple branches, the author can attach multiple patches to the bug report, indicating which patch applies to which branch. Give the capabilities of GIT, this should not greatly disrupt the developer's work flow. (While I'm wishing... it would really be cool to have a hook which updated the bug with the commit id when it was pushed to whichever branch...)

Maybe the entire problem is overblown from my prospective, so I'm certainly open to correction. But with two RMaint cycles under the belt and a staring a third down the throat (Englishism here), I'd love to get this whittled down to size.

[1] http://tinyurl.com/3facmhg