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

[Chris Nighswonger]

Poke.

On Thu, Nov 10, 2011 at 11:49 AM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:
> 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
>>
>