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]

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


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