glibc bug attack

[Roland McGrath <roland at redhat dot com>]

I had hoped that someone would volunteer to be the bug czar and take the
initiative on setting bug database procedures, and I still hope.  But noone
has done anything like that yet, and we need to get the ball rolling.

I hope that everyone who wants to contribute to making glibc maintenance
work better will pull together this week and get some movement in the state
of the glibc bug database.

There are 132 open libc bugs.  For lack of a better plan, you can start
playing around with bugzilla reports to see what we have.  For example:

http://sources.redhat.com/bugzilla/report.cgi?bug_file_loc_type=allwordssubstr&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bugidtype=include&chfieldto=Now&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&gccbuild_type=allwordssubstr&gcchost_type=allwordssubstr&gcctarget_type=allwordssubstr&long_desc_type=substring&product=glibc&short_desc_type=allwordssubstr&type0-0-0=noop&x_axis_field=version&y_axis_field=bug_status&action=wrap&format=bar&width=800&height=350


We've got to start somewhere, so I'll just list some tasks that people can do.
I don't really want to be in charge, so if you have better plans, pipe up.
If you're starting to do one of these things, post about it.

1. In that report you can see a small number of reports with version field
   2.3.2, 2.3.3, or 2.3.4, and more for 2.3.5.  All those versions are
   superceded and there should be no open reports for them any more.
   Current bug reports should refer to 2.3.6 if the 2.3.6 still has that
   bug, or to "unspecified" if it's a problem in the trunk (2.4) or that
   hasn't been exactly classified yet.  Go through all these and update them
   so that either they refer to version 2.3.6 if it looks like 2.3.6 still
   has the bug, or close them if it's been fixed.  Start small, there are
   just a few bugs in each old version.  Here is the URL for a query of
   2.3.2 bugs, and you can use "Edit this query" for the different versions:

http://sources.redhat.com/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&product=glibc&version=2.3.2&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=All+libc+bugs&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

2. Figure out some more useful bugzilla reports and queries and post
   summaries about what's going on with our bugs.

3. Set some bugzilla flags.

   Unfortunately the bug database is in sufficient disarray that the
   bugzilla bug states are not very informative.  But, you can pretty
   well figure that things in NEW state haven't been looked at yet.

   Bugzilla has another feature called "flags", and I set a couple of them
   up in hopes it might be useful to organize our bugs.  (Please chime in
   with more or better flags to add and meanings to define for them.)
   Since we haven't used them before, no old bugs have any flags set.
   You can search on flags specifically (with the "advanced boolean" part
   of the search form), so this should be pretty easy to use for queries
   and reports if the flags and their meanings are useful.

   So far I made two flags: "testsuite", and "examined".

   The testsuite flag should be + when a report includes a patch adding a
   test case to the libc sources (preferably using test-skeleton.c) and
   with a makefile patch so that "make check" runs the test.  When this is
   true and the test reproduces the problem as claimed, and the behavior
   really is a bug, then that makes for an absolutely perfect bug report.
   (The testsuite + bugs are the low-hanging fruit for developers, who
   can just get right to work on fixing the bugs without futzing about.) 

   The "examined" flag is what I hope might be useful right now.  It means
   that the report has been looked at since today and that its fields like
   version, component, etc, make sense and that its bug state is correct
   according to the definitions we decide on for how we're tracking bugs.
   If it's NEW, it really still needs to be looked at for initial triage.
   If it's ASSIGNED, that person really is actively doing something about it.
   What exactly all the states should mean beyond that is up in the air.
   I hope we'll hash it out now.

4. Figure out what to do about tracking bug fixes in two branches.

   We don't have any coherent plan for this now and as a result it's very
   difficult to use the bug database to keep track of what bugs that exist
   in 2.3 were fixed in the trunk and whether they were also fixed in the
   2.3 branch or not.

   One approach is to clone each bug so there is a bug for version 2.3.6
   that is closed only when the bug is fixed in 2.3, and a bug for version
   2.4 (or "unspecified" atm) that is closed only when the bug is fixed on
   the trunk.  The 2.3.6 bug depends on the trunk bug, or something like that.
   Unfortunately the bugzilla on sourceware doesn't have any features to
   make that convenient to do.

   Another idea is something using bugzilla's flags or keywords.
   Figure something out.

   Unfortunately the lack of a plan heretofore means that there are bugs in
   RESOLVED state that were fixed on the trunk and which we're not sure
   they still exist on the 2.3 branch.  A good plan would keep track of
   that in the future, and also go back and figure it out for the closed bugs.

5. Move bugs out of NEW.

   Most bugs are in NEW state, and presumably have not been looked at.  Put
   the bug in ASSIGNED and assign it to yourself if you are looking into
   it, and set examined + on it.  Start by reproducing the bug yourself,
   and improving the test case in the bug.  If you need more information
   put it into WAITING and make sure the reporter knows what to tell you.
   If you can only do a little at a time, then set examined + on bugs still
   in NEW state if you think they are not bogus and have their component
   and version fields set correctly, and their host field if the bug is
   machine-specific or OS-specific ("Target" is meaningless for glibc).

6. Move bugs out of WAITING.

   A lot of bugs are in WAITING state, which means that the reporter should
   have done something.  If the report has been stagnating for a long time
   and the reporter is not doing anything, then you can close it with a
   note to reopen or refile if they really have something to say.  Or, just
   poke the reporter for the needed information.  Even then, you can set
   examined + so we know that WAITING means waiting a short time--because
   you should remember to come back later to close it if you get no response.
   Unless the reporter is about to come back with more information, the
   report should not stay in WAITING.  

7. Come up with good work items for bug triage workers.

   These are just some ideas.  The point of them is to turn our bug reports
   database into something from which we can regularly extract work queues
   of items that need test cases written, items that require working with
   the bug reporters, and items that are ready for developers to spend
   quality debugging time on.  I don't want to make more releases with a
   bug database full of problems we sort of know about, but can't keep
   track of well enough to either fix or explain.


Thanks,
Roland