change in fix-committed practice?
mbp at canonical.com
Wed Aug 26 05:48:13 BST 2009
2009/8/26 Robert Collins <robertc at robertcollins.net>:
> Should we change how we use fix committed/fix released?
> Currently we do: 'committed if its in our branch, released when its in
> But with 2.0 being a long lived target, separate from 3.0 or whatever,
> being in trunk won't be 'fixed' for any bug that we're planning to
> So I'm wondering what will work best to manage this. Do we assume that i
> its not nominated it's not to be backported?
> I'd be inclined to have fix committed/fix released keep meaning what
> they mean and focus on separate tasks for 2.0 backports.
> e.g. target to 2.0, then immediately set to fix committed in that task
> if its fix released || fix committed in trunk.
Good questions; I think I agree with that mode of working except
perhaps not about "if
its not nominated it's not to be backported?"
We should put this into the release cycle or bug handling document but
maybe we should discuss it here first, or actually try it for a bit
before codifying it.
I don't think we should change the meaning of fix committed and fix released.
If something's going to be fixed in an already-released series, we
should make a separate bugtask row for that, and then it can have a
separate status and also be separately sent to a milestone in that
I think the default case should be that we do bugfixes based off the
stable release, and then merge it forward into trunk. I think it
would be getting it backwards to say that we'll assume it won't go
into the stable release if there is no nomination for that series at
the time somebody starts on the bug. Instead, when they start looking
into it, they should make an assessment of whether it can be fixed
there and set the bug tracker accordingly.
The commonsense factors to make that assessment include
* the severity of the bug
* whether the bug can be fixed with an isolated change, or whether
it's more effective to do a larger cleanup
* whether the relevant code has changed substantially between
releases so that a single fix won't fit
* whether users of the previous release seem actually to be bitten by that bug
In general if it's not possible to apply the same patch to both
branches and we would need to fix the bug twice, the severity bar
would be higher.
More information about the bazaar