This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Regression count, and how to keep bugs around forever
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>, hp at gcc dot gnu dot org
- Date: Wed, 19 Dec 2007 01:52:50 +0000 (UTC)
- Subject: Re: Regression count, and how to keep bugs around forever
- References: <571f6b510712181659w64b16ae5ndc32b38de6f5c56c@mail.gmail.com>
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