This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Re: Regression count, and how to keep bugs around forever


On Wed, 19 Dec 2007, Steven Bosscher wrote:

> The bigger issue here, is that people seem to be using Bugzilla as a
> kind-of TODO list for things may some day work on, but probably will

I don't see any problem with that.  It records known issues.  We can then 
use the existing fields, or create new ones, to track how important we 
think those issues are.  I'd rather have known testsuite failures filed 
centrally in Bugzilla than scattered elsewhere.  (Once a testsuite failure 
is filed, it can be XFAILed with a comment referencing the PR, and the PR 
remain open until the bug is fixed and the XFAIL removed.  In principle 
I'd like every XFAIL relating to a GCC bug (as opposed to a bug in system 
libraries etc.) to have an open PR, and any failure present for any length 
of time to be XFAILed and filed in Bugzilla so the normal test results 
show no "expected unexpected" FAILs.)

> The current list of "All regressions" should be a list of bugs that
> people are actively trying to resolve, preferably before the release

No, "All regressions" should be a list of all regressions known.  A list 
of bugs people are actively trying to resolve is useful - indeed more 
useful - but should be called something else.

> To me, the situation is quite clear: If a bug report is open for so
> long, and even the reporter and the responsible maintainer show no
> sign of motivation to work on resolving the bug, I think this tells us
> something about how important this bug is: Not important enough to
> fix.  IMOH we should close such reports as WONTFIX or SUSPENDED to
> make them less visible, so that other bug reports don't fall through
> the cracks.
> 
> So I'm asking for a policy here that says when it is OK to resolve old
> bug without progress as WONTFIX or SUSPENDED. Start shooting.

I objected to the notion of WONTFIX six years ago when we were 
experimenting with Bugzilla, and I object to it now, with only the 
modification: if a bug relates to a feature that has been removed from 
trunk, then WONTFIX is reasonable, and likewise if it requests a fix in an 
old branch for a bug fixed on trunk where we think such a fix is too 
risky.

If a bug requests a feature we decide would be a bad idea, I think INVALID 
is right but don't really care if you use WONTFIX.

If a bug simply hasn't attracted attention, but is still a bug present in 
the current toolchain, it should be left open.  Just because one developer 
won't fix it doesn't justify a declaration that no-one will ever be 
interested in fixing it.

By design, SUSPENDED is an open status rather than a closed one.  Using it 
within the terms of the description in bugs/management.html makes sense - 
go ahead.

-- 
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]