From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: Nathanael Nerode <neroden@twcny.rr.com>,
Wolfgang Bangerth <bangerth@ices.utexas.edu>,
Volker Reichelt <reichelt@igpm.rwth-aachen.de>,
Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>,
ebotcazou@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: your RESOLVED->CLOSED changes
Date: Fri, 23 May 2003 09:36:00 -0000 [thread overview]
Message-ID: <Pine.BSF.4.55.0305231129120.57698@acrux.dbai.tuwien.ac.at> (raw)
In-Reply-To: <3eb901c32106$c561d7b0$c64f2697@bagio>
On Fri, 23 May 2003, Giovanni Bajo wrote:
> The point about flooding the list is that I'm not expecting any RESOLVED
> bug to still be "unresolved". So, once the policy had been decided, I
> would have probably batch-changed all those bugs into CLOSED state
As a side-note: I moved several PRs of mine to RESOLVED, incorrectly
assuming this would "close" them.
Clearly, this was operator error on my side, but it's a data point that
we might consider removing the distinction between RESOLVED and CLOSED.
>> I think the verified/closed distinction is quite useful for noting bugs
>> which are fixed but not in a released version. (Of course some closed
>> bugs are present in 3.3 as of now, but that's an acceptable transition
>> state.)
Wouldn't that make things more complicated, overall? I think it's
perfectly save to add "Fixed on mainline, will be in GCC 3.4" and then
close a PR.
> Eric brought up the same point. What I cannot understand is for whom this
> distinction is useful. Because it's surely not for developers, nor for users
> which rarely greps in the bug database before submitting, and not among
> closed bugs anyway.
Ack.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/
next prev parent reply other threads:[~2003-05-23 9:32 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 [this message]
2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 14:18 ` Wolfgang Bangerth
2003-05-23 15:47 ` Nathanael Nerode
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=Pine.BSF.4.55.0305231129120.57698@acrux.dbai.tuwien.ac.at \
--to=pfeifer@dbai.tuwien.ac.at \
--cc=bangerth@ices.utexas.edu \
--cc=ebotcazou@gcc.gnu.org \
--cc=ehrhardt@mathematik.uni-ulm.de \
--cc=gcc@gcc.gnu.org \
--cc=giovannibajo@libero.it \
--cc=neroden@twcny.rr.com \
--cc=reichelt@igpm.rwth-aachen.de \
/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).