public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Giovanni Bajo" <giovannibajo@libero.it>
To: "Nathanael Nerode" <neroden@twcny.rr.com>
Cc: "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 08:55:00 -0000	[thread overview]
Message-ID: <3eb901c32106$c561d7b0$c64f2697@bagio> (raw)
In-Reply-To: <20030523071817.GA17455@doctormoo>

Nathanael Nerode <neroden@twcny.rr.com> wrote:

>> with these messages. May I ask you to discuss such issues on the main
>> mailing list before doing it? We (bughunters) are trying to mantain Sure.
>
>> and unmantainable. Moreover, we have bugzilla rights to do such batch
>> changes without spamming gcc-bugs.

> I wasn't actually batching them, you know... I caught at least three
> mis-resolved bugs in the process. :-/

Which ones? Were they human errors or script errors?

> I'm not sure why there's no way to poke a bug without flooding gcc-bugs
> (or indeed everyone else on the CC list).

gcc-bugs has been configured to receive mails only on some situations. It's
still not really perfect (for instance, I wouldn't want it to receive a
message for a topic change, I'll have to look into it).
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 (temporary disabling
state change notifications to gcc-bugs for isntance, or just asking Danny to
do it with some script). So I wonder which bugs were mis-resolved.

>> decided yet if we wanted to mantain a difference between "closed"
>> states or
>> not, so we might have to revert all these changes eventually (even if
>> we seem to agree that those states are useless and we simply want all
>> bugs CLOSED). Bugzilla itself might need changes once a policy is
>> adopted.
>
> 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.)

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.

> Given the total lack of QA in GCC at the moment, perhaps 'resolved' is
> not a very useful status, but it's certainly true that only some of the
> currently 'resolved' bugs are actually resolved (I assume this is the
> usual unavoidable conversion glitches).


I don't know the details of the conversion process, but I see that 99% of
the RESOLVED bugs in bugzilla are the bugs that were identified as
duplicates of other bugs. If there are mistakes in this, I think the best
way would be to check manually all those entries, reopening the ones which
are misresolved, and then batch-convert the others to CLOSED without
spamming gcc-bugs.

Giovanni Bajo

  reply	other threads:[~2003-05-23  8:40 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 [this message]
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
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='3eb901c32106$c561d7b0$c64f2697@bagio' \
    --to=giovannibajo@libero.it \
    --cc=bangerth@ices.utexas.edu \
    --cc=ebotcazou@gcc.gnu.org \
    --cc=ehrhardt@mathematik.uni-ulm.de \
    --cc=gcc@gcc.gnu.org \
    --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).