This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: call for assistance: glibc bugzilla triage


> I would be willing to contribute on bugzilla triage but I doubt I could do 
> as well as GOTO by myself. However, I'm not completely sure I understand 
> what is or is not expected. 

As I said, I doubt any one person can do the job we need done.  I hope you
won't be alone for long.  The first thing I expect is for someone to
spearhead the effort, and take the lead on deciding how to go about the
details.  

> 1. handling glibc bugzilla reports as they come in

This means being the default bugzilla owner for most of the glibc
components, and actually being on the hook for saying what the story is
with all of the reports assigned to you.  As well as the ongoing
responsibility for new reports as they are filed, there is the current
backlog of reports.  More or less every report in NEW state needs the full
triage attention and should be reassigned to the triage team, regardless of
who it's assigned to now.

> 2. to filter them into reasonable verified problem reports for developers 
> to work on

This should mean having a test case that is not ungainly to run and that
demonstrates the problem.  Certainly we do put in fixes for reported bugs
that can be plainly seen to be wrong from source examination, but in an
ideal world there is a regression test for every bug.  

It also means discerning whether the cited behavior is really a bug.
Anyone can see the "no, you clobbering your memory is not a malloc bug"
cases.  Other cases are easy enough to tell from reading the POSIX spec.
It is certainly fine and appropriate to ask developers for help answering
the question of whether something is a bug or not.  If it's a quick
determination for a core developer to make, triage folks should certainly
ask for help before spending a lot of strenuous effort trying to figure it
out.  The important thing is that triage whittles down a report into the
analysis of the crucial behavior and the appropriately specific question
about whether that is what it should be doing.

The gold standard for a nicely presented test case is a patch that adds the
regression test to "make check".  That should use the canonical form with
test-skeleton.c, have makefile patches and ChangeLog entries, etc.  (Note
that for such files to be added to libc, their authors must have copyright
paperwork on file.  In most cases, the original reporter's case is simple
enough that you rewrite it completely to make it a nice regression test,
and don't need a copyright assignment or disclaimer from the reporter.)

> 3. to track that the problems get fixed
>
> 4. that the fixes get verified against the reporter's test cases
> 
> 5. that the fixes get merged onto release branches and verified there
> 
> 6. and that reports don't fall through the cracks.

All this hopefully means having the bugzilla states be useful for users and
developers.  If it helps keep track, you can set new bugzilla conventions
for developers and release managers to follow.

> Should I just dive in and try to handle a bug or is there more I should 
> know about what is expected?

Ask all the questions you like, except for, "What should I do exactly and
when?"  Just do it, and ask along the way to figure out if you are doing it
the best way.  

> Also, if multiple people are doing this would will be the default bugzilla 
> owner? Should I just assign bugs I'm working on to myself?

We've never had any sustained, well-oiled arrangement before.  Part of
what's needed is decisive action on choosing the details of new procedures
that will get things done.  I'll give you some thoughts, but you figure out
how you want to manage it.

The bugzilla assignment mechanism is made for keeping track of who is
looking at something.  So I would say, use that to indicate that you are
actually looking at something.  The default owner settings are really just
a convenience for whoever is responsible for keeping an eye on the reports.
Some people like to use a mailing list as the owner, so a team of people
(and lurking volunteers taking on the occasional bug) can subscribe and
then assign bugs to themselves when they tackle one.  It's worth noting
that we already have the glibc-bugs mailing list that is automatically CC'd
on every bug.  That should not be made an owner, but perhaps it already
serves the useful purpose of a mailing list for the triage team.  If you
think a new mailing list is useful (e.g. libc-triage), I can have one made.

I hope you will want to document the details of what triage volunteers
should do and how to go about it.  There should be more web pages talking
about how to manage reports, as well as more and better info for users
making bug reports.  Sign up at https://savannah.gnu.org/projects/libc/
requesting to be a "project member" and then I can give you access to
change the web pages.  The http://www.gnu.org/software/libc/bugs.html page
is the entry point for users reporting bugs (that URL is embedded in the
software now), and it should have contents best suited for someone who just
saw some message telling them to report the crash they just saw.  You can
add whatever other pages you like for documenting your efforts, perhaps
starting from some of the things we've discussed here.

The other useful tidbit that comes to mind is to look at
http://sources.redhat.com/bugzilla/duplicates.cgi and notice the
placeholder bugs for common sorts of useless reports.  These have named
aliases to make it easy to close a bug as a duplicate by typing the name
like bogus-build into the slot.  You can add more of these, and they are
something to document in the triage procedures.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]