[Koha-devel] Patch status workflow (for Bugzilla)

[Chris Nighswonger]

 Hi Ian,

On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls
<ian.walls at 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

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111027/b6a28fe0/attachment.htm>