From: Rask Ingemann Lambertsen <rask@sygehus.dk>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: GCC <gcc@gcc.gnu.org>
Subject: Re: Regression count, and how to keep bugs around forever
Date: Wed, 19 Dec 2007 15:59:00 -0000 [thread overview]
Message-ID: <20071219153201.GH17368@sygehus.dk> (raw)
In-Reply-To: <571f6b510712181659w64b16ae5ndc32b38de6f5c56c@mail.gmail.com>
On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote:
> The current list of "All regressions" should be a list of bugs that
> people are actively trying to resolve, preferably before the release
> of GCC 4.3.
No, it should be exactly what it says it is. If you want an additional
list of bugs that are being actively worked on (and labelled as such),
that's fine (although I have no idea how that list would be useful).
> Instead, it is a mix of high-activity bug reports and bug
> reports where even the target maintainer has been unwilling for 3.5
> years to spend some time on resolving the bug report.
That may be an indication that maintainership should be passed on to
someone else. I don't see how it can be an indication that the bug should
not be fixed.
> So to pick a bug
> report to work on, I need to go through the but report summaries of a
> long list, trying to pick out new regressions between the old
> no-one-cares P4 and P5 regressions.
PR numbers are assigned in ascending order. The newest regressions have
the highest numbers. What exactly is the problem you're facing when starting
with the highest-numbered PRs?
> 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.
Having assigned myself to and/or posted patches for some of the bugs you
want to close as WONTFIX, including four which have four-digit PR numbers,
my response is predictable: No way.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
next prev parent reply other threads:[~2007-12-19 15:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 1:11 Steven Bosscher
2007-12-19 1:14 ` Paul Brook
2007-12-19 1:21 ` Joe Buck
2007-12-19 1:35 ` Paul Brook
2007-12-19 1:46 ` Joe Buck
2007-12-19 3:16 ` Joe Buck
2007-12-19 5:16 ` David Daney
2007-12-19 1:58 ` Joseph S. Myers
2007-12-26 19:25 ` Mark Mitchell
2007-12-19 5:15 ` Weddington, Eric
2007-12-19 14:22 ` Manuel López-Ibáñez
2007-12-19 15:59 ` Rask Ingemann Lambertsen [this message]
2007-12-19 22:19 ` Steven Bosscher
2007-12-20 0:10 ` Rask Ingemann Lambertsen
2007-12-20 1:25 ` NightStrike
2007-12-20 5:05 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071219153201.GH17368@sygehus.dk \
--to=rask@sygehus.dk \
--cc=gcc@gcc.gnu.org \
--cc=stevenb.gcc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).