This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Use of "SUSPENDED" in Bugzilla
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: libc-alpha at sourceware dot org
- Date: Sat, 18 Feb 2012 22:13:33 +0000 (UTC)
- Subject: Use of "SUSPENDED" in Bugzilla
Another thing I've noticed in reviewing open bugs is that there is no
consistency in how the SUSPENDED state is used.
There are 59 SUSPENDED bugs out of 440 open total. Of those 59, 40 are
bugs in the "math" component out of 97 open "math" bugs total. Those bugs
were generally "Suspended until somebody comes up with the patch." or
similar.
I don't think suspending on the basis that noone has yet created a patch
is a sensible use of that state. I'd say that's a feature of any open bug
that is accepted to be a bug: it won't be fixed until someone fixes it.
So SUSPENDED doesn't provide any meaningful distinction from ASSIGNED
here. Maybe noone's working on it, but that's the distinction between NEW
and ASSIGNED, not NEW and SUSPENDED.
So when should we use SUSPENDED? My inclination: SUSPENDED is if there is
known to be something particularly hard about fixing a bug, not simply
that a patch is needed. For example, if a bug cannot be fixed by libc
maintainers on their own because various other components need to change
as well, or because ABI implications make a fix hard (e.g. bug 5945). And
so many of the SUSPENDED bugs should become NEW (and be unassigned from
anyone they are assigned to).
As regards the "math" bugs: I'm not convinced "bug" is a useful
classification of such things as the 7ulp error for log2 in bug 2575. A
greater accuracy would be nice, but is 7ulp all that bad? No standard
requires libm to have particular accuracy for this function. I'm doubtful
that Bugzilla is a good way to track cases where the functions fail to be
correctly rounding; I think it would be better to put these cases in the
testsuite and update the ULPs (which in turn would mean the automatic
tables in the manual show the known errors) and close the bugs; the ULPs
files provide a way of looking for cases where the functions are known to
be inaccurate that's much more amenable to automatic processing than the
bug database. I'd apply it to cases like that 7ulp one - and the 64ulp
case of bug 2541, and even the 770ulp case of bug 2154 (but not the
millions-of-ulps cases in some issues).
--
Joseph S. Myers
joseph@codesourcery.com