Fix Committed/Fix released

John Arbash Meinel john at
Fri Jul 18 16:00:57 BST 2008

Hash: SHA1

Jonathan Lange wrote:
| On Fri, Jul 18, 2008 at 9:29 AM, Martin Pool <mbp at> wrote:
|> On 7/17/08, Robert Collins <robertc at> wrote:
|>> So, at the moment its very low key for developers to manage this status.
|>>  We spend more time per capita in the bug database than users; I
think we
|>>  should continue to keep the overhead low. As such, as long as I don't
|>>  have to fight things to keep the metadata up to date I don't care
how we
|>>  manage it (e.g. 'fix available' on a branch takes what - 4 round trips?
|>>  Thats about 2 minutes from Sydney vs 1 round trip to expand the drop
|>>  down and set to fix committed today).
|>>  Running a script would work too I guess.
|> I think either a script or support in Launchpad would be good.  I
|> don't think it would be efficient to do all these updates by hand.
| We would like to provide this feature in Launchpad.
|> (I see the Launchpad developers themselves apparently do this, and
|> also keep many bugs targetted to particular releases even before they
|> start working on them, which seems to create a huge amount of manual
|> churn...)
| Well... we target bugs and specs to milestones. They then work a
| little like a todo list that we update over a release period. We mark
| the bugs as fix released after the release, but it's generally not too
| cumbersome.
| In terms of manual churn, using Fix Committed to mean fix committed
| and Fix Released to mean fix released is no worse than your current
| process. The difference is just that the churn happens at release time
| rather than at pqm-landing time.
| jml

Actually, no. At the moment when someone announces a branch, we mark it
Fix Committed. Last I checked, there isn't actually a setting for that.
All we really have is "In Progress" on the bug, and maybe "Fix
Available" on the branch. (Though the branch has to be hosted/mirrored
for that.)

If we could mark it Fix Available, then when we merge it to Dev we have
to mark it Fix Committed, and then when we make a release we have to
mark it Fix Released.

At the moment, when someone commits we mark Fix Committed, and when
merged Fix Released. Which at a minimum is 1 less step. (Because we
don't have to change everything *again* when it gets released.)

So *if* we were to use LP as it was meant, the steps are:

1) Take control of the bug, In Progress, start a branch being

2) Do some work on the bug. Probably commit --fixes, which marks Fix
Available on the branch. Still doesn't change the bug status.

3) If it were an option, Fix Available for the bug. Perhaps In Progress
with a branch with Fix Available is enough. However, the bug branch icon
shows up for anything with an associated branch, whether it is Fix
Available or not.

So at the moment, there isn't a way to distinguish bugs that have
someone who started a branch to work on it. Versus someone who thinks
that they have finished working on it.

4) When the branch is reviewed, probably mark the branch as Best Fix

5) When the branch is merged to trunk, mark the bug Fix Committed.
With *our* workflow, we could probably mark the Milestone at this point.
~ As we at least know when the trunk revisions are going to make a
release. Sometimes this could happen earlier, if we knew it was a
Critical bug, etc.

6) When we cut a release, go and change all of the targeted Fix
Committed bugs over to Fix Released.

It is, honestly, quite a bit of overhead for simple bug fixes, and even
a moderate amount for large bug fixes.
We already have a bit of overhead from reviews, needing public branches,
~  going through PQM, etc. Adding a LP round trip for each of those steps
is adding quite a bit. (It might be less if LP loaded a bit faster.)

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list