RFC: bug-handling doc tweaks

[Martin Pool]

2009/8/27 Robert Collins <robert.collins at canonical.com>:
> Poolie and I just had a chat about what bugs need to be worked on next
> (in the context of 2.0 but also more generally).

Thanks very much for updating the actual 2.0 bugs during the call too.

All the bugs that were targeted to 2.0 are now either fixed, critical,
or no longer on 2.0.  To make the rm process require less wasteful
thinking I'll treat that page as containing only release blockers.
Let's not put "would like to" fixes in there because that means every
time the rm looks at it, they need to think about how much they'd like
to fix them.  At any point in time, let's say a bug is either a
blocker or not.  It's ok to be unsure or to change your mind about
whether a bug should block or not, but let's make a decision once, not
every time we read the page.

> http://doc.bazaar-vcs.org/bzr.dev/developers/bug-handling.html
>
> Its worth a refresher I think. The docs don't currently mention release
> blockers in terms of priorities. Later on in the docs we do define how
> we use targeting, so I think this is just a bug in the integration of
> all the docs.
>
> Secondly, having a lot of outstanding branches is bad.
>
> Lastly (and this is a personal pet hate) having a bug assigned to
> someone who isn't actually working on it leads to bugs staying stay for
> extended periods.

pitti makes a case for assignment meaning 'I care about this bug', and
using it as a personal hit list.  He has (he said 100, actually 61)
many more bugs than are actually in progress, and it's fine if people
steal assigned but not in-progress bugs.

I like seeing my assigned bugs as a hit list of bugs I've thought
about if not actually started on.  It's easier to pick one off there
if I have a little time.  This might not be optimal, but I'd rather
settle the other parts of it first.

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.

>
> So I propose to change the Priorities list to avoid the latter two
> issues and include blocker bugs in the guidelines.
> "
>  Priorities
>  The suggested priorities for bug work are:
>
> + 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).
> - 1. Fix critical bugs
> - 1. Get existing fixes through review and landed.
> - 1. Fix bugs that are already in progress.
> - 1. Look at bugs already assigned to you, and either start them, or
> -    change your mind and unassign them.
> - 1. Take new bugs from the top of the stack.
> - 1. Triage new bugs.
>
> It's not strict and of course there is personal discretion but our work
> should be biased to the top of this hierarchy.
> "

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.

I think "fixing things you've started" remains higher than "look at
bugs that are assigned to you but not started"

>
> And under assignment
> "
> Assignment
> Assigning a bug to yourself, or someone else, indicates a real intention
> to work on that bug soon.
> "
>
> I'd like to add "Do not assign bugs to other people unless you are
> confident they will work on them."
>
> This is kindof a no-op statement to add, if someone has read the rest of
> the page, but it does make it clear that the ability to assign in the
> tracker is not the same as asking someone to look at the bug. (It is for
> some people, but not everyone :)).

It's probably a reasonable way to say "will you look at this" which is
different to "I assume you're going to do this."

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