Re: GCC 4.4.0 Status Report (2008-11-27)

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

On Tue, 23 Dec 2008, Kai Henningsen wrote:

> Am Thu, 27 Nov 2008 18:30:44 +0000 (UTC)
> schrieb "Joseph S. Myers" <joseph@codesourcery.com>:
> 
> > There are a total of 5150 open bugs in Bugzilla, counting both
> > regressions and non-regressions.  It seems quite likely that many of
> > the older bugs have in fact been fixed since they were filed, but we
> > don't have any good procedures for occasionally reviewing bugs to see
> > if they are still applicable to current trunk.
> 
> Assuming some random volunteer wants to take a stab at (part of) this,
> what would (s)he need to do so this is actually useful, and especially
> how would (s)he best communicate their results?

There's a "Last confirmed" field in our Bugzilla, so selecting "Reconfirm 
bug" is useful whenever you have indeed managed to confirm the bug.  
Similarly, updating "Known to work" and "Known to fail" is useful.

Obvious things to consider: can you reproduce the bug with trunk and 
confirm that it is indeed a bug?  If so, update those fields, and move 
from UNCONFIRMED to NEW if still in UNCONFIRMED.  If a regression, add the 
regression marker in the summary and set the milestone.  If it's an old 
bug you can't confirm because you don't have the target, ask the submitter 
to reconfirm (and put in WAITING).  If it's been in WAITING a long time 
without feedback (see "View Bug Activity") then close for lack of 
feedback.  "bootstrap" bugs especially need reconfirmation after a while.  
For bugs reported for testcase failures, gcc-testresults may be helpful 
(but watch out for the tests having been XFAILed rather than fixed - bugs 
associated with XFAILed failures should remain open until the problem is 
actually fixed).

Consider whether the bug is in the right component.  Components such as 
"c" and "c++" should be for bugs in those front ends, not for bugs in 
other parts of the compiler with testcases in those languages.  
"regression" is for automatic regression tester reports that need filing 
manually in another component.  Some bug reports may not in fact reflect 
any GCC bug and so should be closed as invalid, or may have too little 
information to tell whether there is a bug in which case they need to go 
in WAITING with a request for that information.

If the bug appears only to apply for a target that's now been removed, it 
may be possible to close it.

If the bug is a duplicate of one you reviewed earlier, you can mark it as 
such.

If you and the original submitter can no longer reproduce a bug, closing 
it as fixed will generally be appropriate unless there is reason to 
believe that the underlying problem is still present and the bug has just 
gone latent.  Identifying the fix may of course be useful and make certain 
that the bug can be closed.

If the bug has been in ASSIGNED for a long time, ask if the person 
assigned is actually working on it - if they aren't working on it any 
more, they should be unassigned.

In general, anything that's appropriate when reviewing bugs just after 
they come in is appropriate in reviewing old bugs, but it's also likely 
there are a fair number of bugs that were quietly fixed by someone who 
didn't know about the bug report in question.

If a bug is very easy to fix, fixing it would be great.  If there's a 
patch attached by an unknown person, they should be pointed at the 
instructions for contributing.  If a patch was submitted to gcc-patches 
and not reviewed, asking the submitter to ping it or retesting and pinging 
it yourself may be good.

I think going through bugs by component would be a reasonable approach to 
this.

-- 
Joseph S. Myers
joseph@codesourcery.com