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

[Chris Nighswonger]

Now that KohaCon is past, I'd like to see us come to a resolve on this issue.

On Thu, Oct 27, 2011 at 10:48 AM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:
> 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
>