Re: bugzilla practices

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 22 Feb 2012, Roland McGrath wrote:

> 1. UNCONFIRMED
> 
>    What about starting to use UNCONFIRMED as the initial state and having
>    triagers change to NEW after reproducing the problem, weeding out user
>    error, requesting obvious missing information from the reporter, etc?

I think that's a good idea.  Marek Polacek also suggested it on #glibc.

In the course of going through "math" bugs I've found quite a few from 
2006 that were invalid (once you worked out the argument actually passed 
to the function, taking into account C semantics and type conversions) but 
where their validity had never been checked before - an explicit 
indication of whether someone has checked the bug is good.

One thing to watch out for is losing this information if a bug goes to a 
state other than NEW - if it's closed then REOPENED there's no indication 
of whether that's reopened and confirmed (the intended fix didn't actually 
resolve the problem, or had to be reverted, or whatever), or reopened but 
unconfirmed (closed as invalid but there was disagreement with that, for 
example).  (For SUSPENDED I think the policy we have more or less implies 
that a bug needs to be known to be valid to suspend it.  And hopefully 
once a bug is confirmed there won't be any need to put it in WAITING.)

>    What I have in mind is that we may have two distinct classes of people
>    who look at bugs:
>    * developers, who intend to fix bugs but want to focus their time on the
>      actual debugging
>    * triagers, who want to help but may lack the expertise to actually fix
>      many bugs

Those would be overlapping classes.

> 2. Recruit a triage team!

Yes.  Or encourage people to get involved, anyway, even if not explicitly 
recruiting to a specific role.

>    IMHO this can be an excellent entry point for new contributors to the
>    project.  It can be pretty easy to ramp up and does not require much

Depending on what the triagers do it's also open to people who aren't able 
to complete copyright assignments for whatever reason.

> 3. Mandatory bugzilla filing for user-visible bugs
> 
>    I think we should get to a system where (at least) every bug that might
>    have affected an end-user is filed in bugzilla.

Reasonable, though we need an understanding of what's meant by 
user-visible.  (Various of my sys/*.h -> bits/*.h changes fixed problems 
of some SPARC headers not having been updated for API changes in the main 
header - that could have affected any users trying to build with the 
particular API that hadn't been added to the SPARC versions.  Does that 
count as user-visible?)

>    If someone just sends a patch cold to the mailing list, we should get it

A patch for a bug, that is, as opposed to a cleanup or new feature.

> 4. Auto-annotation on git commits

Yes, that would be a good idea.

> 5. Formalize out how bugzilla use relates to release branches
> 
>    I think Carlos may already have pretty much settled on this.
>    But how we do it is not really clear to me from reading the wiki page.

I only found when adding to the procedures that some suggestions of mine 
from 2009 had got on the page.  I marked them as possibly not current.  I 
think Carlos has sorted out how to handle Bugzilla use after branching - 
but how to use Bugzilla to work out whether we are ready to branch and tag 
is less clear, and that's what my suggestions from 2009 were more about.

-- 
Joseph S. Myers
joseph@codesourcery.com