This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: your RESOLVED->CLOSED changes


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]