Re: Use of "SUSPENDED" in Bugzilla

[Aurelien Jarno <aurelien at aurel32 dot net>]

On Sat, Feb 18, 2012 at 10:13:33PM +0000, Joseph S. Myers wrote:
> 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).

I agree, sounds reasonable.

> 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).
> 

The main problem is that if a new test is added without updating the
ULPs, the test code assumes 0 ULP and in most of the cases the test
fails. That's what happened with the new jn tests for which I have sent
patches to update ULPs for the various architectures.

The bugs you are talking about are very old bugs, and they look more
like "hey the math testsuite doesn't pass" than "I would like more
precision in foobar math function". Given the math testsuite currently
passes for most architectures, I think the bugs can simply be closed.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net