Le 26/10/2011 18:54, Chris Nighswonger a écrit :
On Tue, Oct 25, 2011 at 11:36 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@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