RFC: bug-handling doc tweaks

Martin Pool 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
> if:
>  - 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
>> it.
>
> 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
>> critical.
>
> 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
that.

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.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list