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

[Paul Poulain]

Le 26/10/2011 18:54, Chris Nighswonger a écrit :
> On Tue, Oct 25, 2011 at 11:36 AM, Paul Poulain
> <paul.poulain at biblibre.com <mailto:paul.poulain at biblibre.com>> wrote:
> 
>     > The Workflows allow us to specify how tickets are allowed to change
>     > status, from which to which.  Here's an example workflow:
>     >
>     >   * NEW (default for all incoming tickets)
>     >   * ASSIGNED (to the developer working on it)
>     >   * NEEDS_SIGNOFF (once a patch has been submitted)
>     >   * SIGNED_OFF (after signoff)
>     >   * PASSED_QA (once QA'ed successfully)
>     >   * PATCH_PUSHED
>     >   * RESOLVED
> Speaking as a third-term release maintainer (fwiw), I would like to see
> an additional patch status added to be known as NEEDS BACKPORTING.
I feel it should not be a status but another field. When should we set
"backporting" ? after patch pushed ? in which case ? aren't all bugfixes
supposed to be backported to stable ?

> This
> will allow for a quick search by the release maintainer to see what
> people expect to be backported. The simple distinction between
> enhancement and bug disappears once an enhancement has made its way into
> master and/or the current stable release and bugs are filed against it,
> thus making it hard to know just by looking at the git bug-branch or
> bugzilla nomenclature. Setting the patch status to NEEDS BACKPORTING
> would greatly ease this job.
...OK, got it (the answer to my question just below)
So I've a proposition : all bugs should be version rel_3_6, all ENH and
bugs attached to ENH should be version rel_3_8
version "master" being dedicated to ENH that still haven't made their
way to rel_3_8.
So you could find all bugs that needs backporting : all patches attached
to rel_3_6 !

makes sense ?
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08