want to indicate intention to fix a bug when branching

[Stuart Bishop]

bzr commit supports a --fixes argument, which creates a bug/branch linkage with 'fix available' status. During dogfooding, Launchpad developers seem to find that this isn't flexible enough.

It would be great if there was more control over this, allowing a developer to flag a branch as 'fix in progress' of a bug instead of having to manually set the status of the bug to 'in progress' and create the bug/branch link.

It would be great if there was an option to link a bug to a branch with a 'fix in progress' status on branch creation.

If we know when work started on a bug fix, and when it was completed, it would make this metadata useful for selecting a sequence of revisions for a cherry pick. Because bzr is a decentralized VCS, small commits are encouraged and a particular bug rarely fixed by a single revision (particularly if you use TDD or other Agile practices).

A possible workflow could look like this:

bzr branch --fixing=lp:42 lp:launchpad bug-42 # Branch linked to bug-42 as 'fix in progress'
[...]
bzr commit --fixing=lp:43 --fixes=lp:44 -m 'Rebuild OpenID RP configuration navigation page'
[...]
bzr commit --fixes=lp:43 -m 'Add batching to OpenID RP configuration navigation page'

This is still somewhat backwards though, as we should be able to specify the linkage when we think of it rather than waiting until we commit and hoping we remember. This could be done by storing the metadata change as a seperate revision under the hood as if the user had done 'bzr shelve; bzr commit --fixes=... --unchanged; bzr unshelve'. Or it could be stored in a pending state like pending merges.

bzr branch lp:launchpad bug-42
cd bug-42
bzr fixing lp:42
[...]
bzr fixing lp:43
[...]
bzr fixed lp:44
bzr commit -m 'Rebuild OpenID RP configuration navigation page'
[...]
bzr fixed lp:43
bzr commit -m 'Add batching to OpenID RP configuration navigation page'

Or should commit --fixes be dropped in favor of register-branch and register-branch enhanced?

[Björn Tillenius (bjornt)]

I'm one of those who think the --fixes workflow is a bit tedious to use, and thus I end up never using it.

For me, just doing 'bzr branch --fixes lp:42' would be ideal. I don't think there is much value in recording exactly in what revision a bug was fix, because usually it's not only one revision. I find there is much more value (especially in comparision to the work required) in saying that "this branch fixes this bug". It's not important to indicate whether it's fixes. If the branch is ready for review, the bug should be consider fixed in that branch.

The only time I would like to indicate that a bug was really fixed, would be when the branch gets merged into mainline. For Launchpad that means that pqm-submit would need to support --fixes as well.

Of course, having a command like 'bzr fixing' would be useful to add bugs to the branch after it has been created.

[Jonathan Lange (jml)]

I've been talking about things like this with various bzr & Launchpad developers for the last few weeks.

Some thoughts:

 * One should be able to declare that a branch is intended to fix a set of bugs at branch creation time.
 * bug-branch link statuses are going to die -- see bug 274610
 * I don't think that enhancing register-branch is the right solution for this problem. It's main purpose is for supporting mirrored branches. It should do only that and do it well.
 * Different projects have different opinions about when a bug is "fixed". Launchpad uses "fix committed" to mean "the fix is on trunk", Bazaar uses "fix committed" to mean "there's a fix in a branch".
 * I think it's useful for Launchpad to record when a non-trunk branch fixes a bug. This feels more "dvcs" to me.
 * If we want to design a feature, we should probably use a wiki page rather than a bug.

[Jonathan Lange (jml)]

I'm marking this as incomplete, since we should turn this into a plan & a bunch of bugs.

[Martin Pool (mbp)]

So it seems like the gist of this is, you want to associate a bug and branch before the bug is actually fixed? That makes sense.

As jml says it needs some kind of discussion. It would be somewhat easier to do the ui in Launchpad, but might be easier to use with client support. Maybe it's best to do it in lp first then see what kind of commandline api client would help.

[Jonathan Lange (jml)]

We had another discussion about this on the Launchpad mailing list recently. I'd like to thrash out some ideas at UDS. For the moment, I'll close this bug on launchpad-bazaar since I don't think the tracker is the best place to get this ready to code, and since it's being tracked elsewhere.