using bugzilla for libc

[Roland McGrath <roland at redhat dot com>]

The bugzilla setup now in use on gcc.gnu.org is going to be available for
tracking bugs in glibc as well (also binutils).  Not quite all the pieces
are in place yet for using bugzilla, but an important step now is to figure
out how we're going to use it.  (In case anyone didn't know, the gnu.org
gnats setup has been utterly unusable for a long time, and now the host is
completely dead; we've given up on it completely.  It remains to be seen
whether the old data from gnats reports can be salvaged, or even should be.)

What you can do right now is go to

	http://sources.redhat.com/bugzilla/ 

make yourself an account, using whatever email address you want bugzilla to
send you mail at.  This is on the same machine as gcc.gnu.org/bugzilla, but
is a distinct database with separate accounts, so if you already use GCC
bugzilla, that's not directly relevant (except you already know how to use
it).  Note there is no SSL for this site; it is all insecure.  So be sure
not to use a password there that you use for anything else.

There is a mailing list for people involved in shepherding the bugzilla
setup (for GCC and the new one).  You don't need to get on that mailing
list unless you want to worry about administrivia and picayune technical
issues with bugzilla itself.  (I'm on it to represent glibc developers' use
of bugzilla, and I'll let you know here if anything interesting comes up.)
But if you want to get on it, mail <bugzilla-masters-subscribe@dberlin.org>.

The utility of having a functioning bug tracking system for libc
development will hinge on us establishing ways to use it efficiently and
productively.  GOTO Masanori <gotom@debian.org> has volunteered to do
bug triage, and bugzilla being useful will depend greatly on these efforts.

The first thing I would like to discuss about using bugzilla is a set of
components.  (There are several other important issues on my agenda to
figure out, but I'm going to get the ball rolling just with this one and
bring up the others after your initial feedback.)  In bugzilla's parlance,
glibc is our "product" and we get to pick a set of "components" into which
it's divided up for purposes of grouping bug reports.  The essential
meaning of a component is that it has an owner, which is the person
assigned to contemplate the bug report first.  It's also a selector easy to
use in queries when you are collecting lists of bugs.

In the case of libc, you could call a zillion things "components"
logically, or say it's all just libc.  I think the useful kind of component
to distinguish is along the lines of how things are maintained in practice.
Here is an initial set of components off the cuff, with a tentative idea of
who the "owner" might be.  This is just an example of what we might use.
I'm asking for ideas.

regex		jakub
nis 		kukuk
linuxthreads	jakub
nptl		drepper
manual		roland?
localedata	pere
libm		<triage>
libc		<triage>
rtld		<triage>

<triage> means gotom, but perhaps instead a pseudouser that is a mailing
list of multiple volunteers.  Any of the others might also instead be a
mailing list: manual-triage, localedata-triage, etc.  The idea is that
e.g. locale-related reports would go initially to Petter (or his group of
volunteers), who would verify the problem, work out a good concise test
case and perhaps a fix, and post to libc-hacker for help (or just approval
if they fixed it).  Likewise, most bugs would go to Masanori (or his group
of volunteers) who would then reclassify them to the appropriate component
and (unless reclassified to a component with its own triage team, like
localedata) verify them and post the concise reports to libc-hacker.  If
someone on the list starts looking into the bug, he should update bugzilla
to show it assigned to him, then update it again when the fix has been
committed.


Comments?


Thanks,
Roland