Bug states, Bugzilla docs (was: Re: Use of "SUSPENDED" in Bugzilla)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 21 Feb 2012, Roland McGrath wrote:

> I concur with Carlos's assessment of how to treat SUSPENDED.
> In fact, I've never been clear on what that state was really for.
> I think the wiki should explicitly describe all the bugzilla states
> in a tabular form that makes it easier to look up.

I have added a table to 
<http://sourceware.org/glibc/wiki/bugzilla/procedures> as a summary of 
states.

I think we now have adequate documentation of Bugzilla practices at 
<http://sourceware.org/glibc/wiki/bugzilla/procedures> and 
<http://sourceware.org/glibc/wiki/Bug_Triage>, with information for bug 
reporters at <http://www.gnu.org/software/libc/bugs.html> that is also 
sufficient and current.  The bits about milestones are marked as possibly 
non-current since we need more experience to work out what's useful in 
release management.

I don't think we have a major need now for any more documentation (beyond 
the list of default CCs) or proposals regarding bug management in general, 
but I'm sure more issues will come up as people work on bugs; as and when 
people find such issues they should propose solutions and update the wiki 
as appropriate (but for the most part documented procedure will need to 
follow practice).

We are also clearly doing a lot better than we used to at having people 
review new bugs, comment, try to ensure they are reproducible and as 
appropriate fix them.  This is definitely being done collectively now 
rather than just by a few default-assignees who were either inactive or 
only intermittently active - though we could still use more bug reviewers.

We could certainly do with more people reviewing existing bugs, giving a 
fresh eye to whether they are valid, reproducible, etc., ensuring they are 
in the right state and not default-assigned to someone not working on 
them, pinging / resubmitting any patches and trying to fix a reasonable 
proportion of them.  I've thoroughly gone through "ports" and 
"linuxthreads" and intend to continue working on "manual" and "math" as 
well as fixing various bugs elsewhere.  I hope some other people will help 
work through other components.  But getting the existing bugs into shape 
is probably quite a long-term issue to be addressed as the community grows 
and there are more people able to do this.

> I don't have any particular opinion on the math issues.

Does anyone else have comments on this?  The issue is how to handle bugs 
of the form that some function's accuracy on some input is less than ideal 
- I think that since there could be an almost infinite number of such bugs 
for different functions and inputs, and given that we have a structured 
way of representing such inaccuracy in the ulps files which finds its way 
to the manual to inform users of known inaccuracy, it's most useful to 
ensure that specific testcases given are entered in the testsuite and ulps 
files, then mark such bugs (where the number of ulps is not excessive - up 
to 999 say, not millions) as duplicates of a general 
quality-of-implementation bug for this issue, which would direct people to 
the ulps files for specific cases of known inaccuracy.  Bugs would only be 
marked as duplicates after the specific testcases they give are in the 
testsuite.

-- 
Joseph S. Myers
joseph@codesourcery.com