From: Nathanael Nerode <neroden@twcny.rr.com>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc@gcc.gnu.org
Subject: Re: your RESOLVED->CLOSED changes
Date: Fri, 23 May 2003 15:47:00 -0000 [thread overview]
Message-ID: <3ECE422A.4010106@twcny.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utexas.edu>
Wolfgang Bangerth wrote:
>>Right now, in order to change to CLOSED, you need to edit the bug two times,
>>and this is suboptimal.
>
>
> I wasn't even aware of this. Which might or might not indicate that the
> process is too complicated.
>
> Regarding the existence of the two states at all: I have argued previously
> that that's unnecessary. Nathanael says that we need them for the
> otherwise lack of QA in gcc, but I think that's not correct: every patch
> for a bug should come with a testcase, so at least in theory a bug that
> has once been fixed cannot reappear because it would show up in the
> testsuite.
Note that I'm arguing for "VERIFIED", not for "RESOLVED". I agree that
the presence of *three* states (RESOLVED, VERIFIED, and CLOSED) is
undesirable. The point of VERIFIED is to hold the bugs which are "fixed
on mainline, not for 3.3", which can keep getting duplicate submissions
for many months. (And we should, if we keep it, make VERIFIED bugs
searched by default by users looking to submit a new bug without
duplicating an old bug.) RESOLVED serves no separate purpose for GCC.
> I get the feeling that this requirement is quite thoroughly handled. If it
> is not in some cases, then I think it is an undue burden on the bugzilla
> people if they have to maintain two states for _all_ bug reports. It's an
> undue burden because it can't be their responsibility to enforce the
> testcase rule, but they would be forced to bear the consequences.
>
> I would also like to posit that quite a number of bugs will then stay
> RESOLVED indefinitely. If someone, say, fixes a bug on mn10200 or some
> other obscure target, who's going to double-check after a release and put
> in into CLOSED?
Yup. Well, me, but other than that. :-)
next prev parent reply other threads:[~2003-05-23 15:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-23 7:39 Nathanael Nerode
2003-05-23 8:55 ` Giovanni Bajo
2003-05-23 9:36 ` Gerald Pfeifer
2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 14:18 ` Wolfgang Bangerth
2003-05-23 15:47 ` Nathanael Nerode [this message]
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:46 ` DJ Delorie
2003-05-23 19:56 ` Wolfgang Bangerth
2003-05-23 20:03 ` DJ Delorie
2003-05-23 20:14 ` Wolfgang Bangerth
[not found] ` <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utex as.edu>
2003-05-23 14:19 ` John Anthony Kazos Jr.
2003-05-23 15:41 ` Nathanael Nerode
2003-05-23 15:33 ` Nathanael Nerode
2003-05-23 9:43 ` Joseph S. Myers
[not found] ` <Pine.LNX.4.53.0305231035220.4682@kern.srcf.societies.cam.a c.uk>
2003-05-23 9:53 ` John Anthony Kazos Jr.
2003-05-23 15:05 ` Daniel Berlin
2003-05-23 15:54 ` Nathanael Nerode
-- strict thread matches above, loose matches on Subject: below --
2003-05-23 15:29 Volker Reichelt
2003-05-23 16:18 ` Daniel Berlin
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:37 ` DJ Delorie
2003-05-23 14:55 Wolfgang Bangerth
[not found] <20030523062858.322.qmail@sources.redhat.com>
2003-05-23 6:59 ` Giovanni Bajo
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=3ECE422A.4010106@twcny.rr.com \
--to=neroden@twcny.rr.com \
--cc=bangerth@ices.utexas.edu \
--cc=gcc@gcc.gnu.org \
/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).