bugzilla practices

[Roland McGrath <roland at hack dot frob dot com>]

I would still like to see some more development on bugzilla practices.
In no particular order:

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?

   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

   So developers with limited time who want to maximize the use of their
   rare expertise would look at NEW bugs but not UNCONFIRMED ones.

   This notion is only useful if we get a significant active team of
   triagers.  But that's something we could really use.

2. Recruit a triage team!

   This is http://sourceware.org/ml/libc-alpha/2005-10/msg00057.html
   but >6 years later, and this time with feeling.
   
   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
   prior expertise or experience.  The work comes in tiny bite-sized
   morsels, so doing a tiny bit every day helps and doing big spurts from
   time to time helps, whatever fits in with a particular person's life.
   It trivially scales to roughly arbitrary numbers of people pitching in.

   http://sourceware.org/glibc/wiki/Bug_Triage is already a fairly decent
   introduction.  Perhaps it could be improved, or made more friendly and
   inviting.  I don't know what would work to drum up volunteers.  Maybe
   some pleas on libc-help?  Elsewhere?  Someone could become a "glibc
   ambassador" and go wherever people go to find volunteers for things?

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.

   If someone just sends a patch cold to the mailing list, we should get it
   filed in bugzilla.  (That could be either by asking the poster to do it,
   or by developers/triagers watching the list filing it.)  Bugzilla is the
   mechanism we have for tracking and recording what things have been
   recognized as broken and then fixed.  If users later come across the bug
   in a previous release version, they can find the fixed bug in bugzilla
   and either know a major upgrade will cover it, or they can request a
   backport to a release branch.  Triagers can resolve previously-fixed
   bugs as duplicates of past known issues rather than just works-for-me.

   There's no need for this in cases of bugs/regressions just introduced
   during development and never let out into a release.  And we don't need
   to be thorough hard-asses about it to start with, but I think we should
   try to get to a place where the bugzilla database is a reliable
   repository of what problems have been or could have been observed by
   users.

4. Auto-annotation on git commits

   We used to have this under CVS, based on regexp matching of the
   ChangeLog [BZ #nnn] convention.  We should get someone to figure out
   implementing that for git now.  (I'm inclined toward doing it based on
   the ChangeLog diff in the commit as we did for CVS.  But we could also
   do it based on a convention for BZ# tags in commit log messages if that
   is greatly easier to implement.)

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.

That's all that is popping to mind just now.  But I think it's worthwhile
in general to try to evolve in the direction of whatever other such
formalisms people think of either that make bugzilla itself a more useful
resource for users, triagers, or developers, or that make workflow smoother
and nicer for developers and triagers.


Thanks,
Roland