RFC: bug-handling doc tweaks

Robert Collins robert.collins at canonical.com
Thu Aug 27 04:28:50 BST 2009


On Thu, 2009-08-27 at 13:09 +1000, Martin Pool wrote:
> > 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.

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?".

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.

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.


> 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.

> > 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.

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 "fixing things you've started" remains higher than "look at
> bugs that are assigned to you but not started" 

I put that the way around I did based on having that list be extremely
short: it should be only a moments work to notice that someone has asked
you to look at something and decide that you either will, or won't, look
at it. Whereas finishing the current bug might be a days work, and
whoever asked you to look at their bug will either come nagging, or be
delayed.

-Rob

*:
<https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=status&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.importance%3Alist=CRITICAL&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090827/846b40c1/attachment-0002.pgp 


More information about the bazaar mailing list