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:
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:
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.
|Free forum by Nabble||Edit this page|