On Tue, 23 Dec 2008, Kai Henningsen wrote: > Am Thu, 27 Nov 2008 18:30:44 +0000 (UTC) > schrieb "Joseph S. Myers" <jos...@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 jos...@codesourcery.com
