RFC: bug-handling doc tweaks
mbp at canonical.com
Thu Aug 27 05:02:46 BST 2009
2009/8/27 Robert Collins <robert.collins at canonical.com>:
> I don't touch bugs assigned to other people, by default. I can't tell
> - they have work they haven't written about
> - haven't touched it
> And while there are plenty of things to do, I'll just go to the next
> one. This is ok, I guess, for wishlist or low priority bugs, but its
> actively bad for critical or targeted bugs. It leads to latency and
> discussions like "this is assigned to you, are you working on it?".
There really is a set of bugs that I've thought about but not
necessarily written about or written code for. The bug tracker
reflects that. People do have to make a judgment call about whether
to talk first or just go ahead.
> Perhaps using a tag 'mbp-fave' or something would be good. It would have
> the added bonus that I can see that you'd love to see it fixed, even if
> it is a wishlist.
That could be good. Tags are harder to use than assignment though,
which is itself a bug.
> Or you could use the 'affects me too button' - perhaps launchpad gives
> you a convenient list of 'these affected me too', which would make a
> good personal todo list.
It doesn't, there's a bug for that.
To be honest I can see there is a problem here but I don't want to
think about it this week.
>> The way I'd propose to use it is:
>> Inprogress bugs should be assigned.
>> Assigning bugs to yourself because you're interested but not yet
>> started is fine. It does not denote an exclusive lock or a commitment
>> that you will actually do it.
>> Assigning bugs to someone else is not a reliable handoff that they
>> will actually do it.
>> In other words its up to the assignee how they want to use it. If it
>> turns out that having a small queue there is optimal we can recommend
> I think what you propose is fine /except for/ assigning to yourself to
> indicate interest, as opposed to activity.
OK, though see above.
>> I'd rather have 'critical bugs' at the top of that list because
>> there's an easy stable url to find them, otherwise you need to look at
>> all possibly relevant releases. Most targeted bugs should be
> So, you'd prefer:
> + 1. Progressing bugs that are critical.
> + 1. Progressing bugs targeted to a release.
> + 1. Get existing fixes through review and landed.
> + 1. Look at bugs already assigned to you, and unassign them
> + if you're not going to work on them at the moment
> + 1. Handle uncomfirmed bugs to the extent of deciding if its critical
> + or high.
> + 1. Fix bugs in priority order (claim the bug if its nontrivial).
> I don't think that that will work well at the moment:
> https://bugs.edge.launchpad.net/bzr/+milestone/2.0 - 6 bugs open
> critical bugs list [*] - 12 bugs open
> We can ask for a report page in launchpad to give us a stable milestone
> url, but until then its really not that hard to know 'we're working on
> 2.0.1 and 2.1b3'
> Even if we coerce all targeted bugs to critical, which I think has its
> own significant issues, we wouldn't be showing an accurate list.
I think here you're running into the fact that the list is a guide not
a straightjacket, and that our existing bugs are imperfectly filed.
If people do either targeted or critical bugs first or use their own
intelligence it will be fine.
It's also true that I don't want people triage all the existing bugs
before fixing any bugs, but I don't expect anyone would actually do
Similarly with assigned bugs vs in progress bugs - there may be no
strict priority between looking for work and doing work, or at least
not one you can formally document.
More information about the bazaar