managing bugfix branches is more work than necessary

Quoting the full text of the initial bug submission, so editing the bug
description will not confuse the discussion.

John A Meinel wrote:
> If you create a new Bazaar branch when fixing a bug, there are a lot
> of extra steps/clicks necessary when you need to mark the bug as
> fixed and the branch as merged.
>
> I realize there is some discussion of ways to do this automatically,
> but that can be error prone, and until it is implemented it still can
> be useful to make the manual process more streamlined.
>
> These are the steps needed to close the bug:
>
> 1) Go to the bug page
> 2) Open up the bug status, and mark it as fix released, possibly add
> a version number, and message, and submit.
> 3) Click on the associate branch link
> 4) Click on the link to the actual branch page
> 5) Click on the link to change the branch status
> 6) select 'merged' from the list, and submit.

In my opinion, the BugBranch status should just be removed. What do you
think?

> One possibly improvement would be to get rid of the 'associated
> branch' page, and instead fold that into the actual branch page. So
> if a branch is associated with multiple bugs, it could get multiple
> sub pages. Similar to how Bugs associated with multiple upstreams are
> handled.

That definitely makes sense. It even fits with the current URL
structure. Though when that is implemented, that will probably not be as
fancy as the bug page.

> Also, when setting the overall branch status, the actual branch
> status is sort of hidden in a small square on the left, which is not
> clickable. And to change the status is on an entirely different page
> from a link which is far away.

This is an general issue with the Launchpad UI design. The branch page
is being consistent with the rest of Launchpad. You should talk with mpt
(Matthew Paul Thomas) about it. This should be further discussed as a
separate bug.

> Also, you can't change the status on
> the details page, which means there are multiple pages for handling
> the information about a branch.

That is also a general issue with the Launchpad UI design. The
specification tracker makes the most heavy use of this. Many objects
have a status which is editable only in a separate form: branches,
specifications, requests...

> Understandable some are more stable information, (branch description,
> etc) versus more variable (current branch status). But these should
> be unified.

I rather agree with you on this. If you can get mpt to add a comment to
that bug to support this change, I will see that it is done.

I should read over this and figure out what's still missing.

AIUI, this bug is about providing an easy way to say, "this branch fixed this bug and it has now landed on trunk". Although it would be nice to have, we are focusing on more automatic ways of achieving the same.

We only need to track this on launchpad-bazaar

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/487900 contains an easy to see example of how this could be improved:

Martin Pitt, arguably one of the most prolific people on launchpad, had to manually enter a "trunk r1693" bread crumb in comment 9 if he wants any kind of back tracking to know which commit actually applied to that bug. Multiply the time he spends doing that across the number of commits he makes, and it adds up to meaningful time, not to mention, massive opportunity for typos. Instead, when the branch is first linked, the commit number could have been added for him automatically.

Even better, it would be helpful if the commit number was placed in the "Related branches" section so that people would not have to wade through who knows how many pages of comments to find someplace where the developer might or might not have left a bread crumb. Better still, where ever it is listed, a clickable link to the actual commit would save people further time. This would bring launchpad closer to having the same ease of use for change management tracking that trac has.

This would also greatly help with the fact that most developers aren't as nice as Martin, and actually don't leave bread crumbs with commit numbers, so anyone trying to code review, audit, or otherwise view the change that applies to that ticket must waste their time trying to figure out which commit number contained the actual change.

The only issue that has not been addressed from this bug is the automatic marking of bug statuses on merge. There is already a bug about that open.