your RESOLVED->CLOSED changes

your RESOLVED->CLOSED changes

[Giovanni Bajo]

neroden@gcc.gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:

> --------------------------------------------------------------------------
--
>              Status|RESOLVED                    |CLOSED


Hello Nathanael:

I of course appreciate your work, but you are basically flooding gcc-bugs
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 gcc-bugs
in a decent readable state, and right now people are willing to purge their
directories because of these floods, making the whole mailing list useless
and unmantainable. Moreover, we have bugzilla rights to do such batch
changes without spamming gcc-bugs.

Besides, we were discussing the whole VERIFIED/RESOLVED/CLOSED issue
off-list (and once we would have found an agreement among ourselves, we were
going to bring the issue on the list of course). Theoretically, nobody
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.

Thanks for your cooperation.

Giovanni Bajo

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

As a general note up front: I've certainly seen a good number of PRs, but 
at most a dozen or so (out of 11k) which have been reopened because they 
were not fixed. Out of these, most read something like "problem reappeared 
in original testcase" (as opposed to some small testcase that was fixed). 
I believe that for all practical purposes, the set of PRs closed with 
someone claiming it is fixed but it wasn't is really empty.


> In the cases you're talking about, the cron job would automatically
> close the PR shortly after it's fixed.  This doesn't require extra
> people at all.

What's it good for, then?

> In the cases I'm talking about, the originator would have a window of
> opportunity to test the fix and reject it if it doesn't happen to fix
> it for them.  I've been burned too many times with my bug reports (er,
> not gcc, but for other projects) being closed without being fixed, and
> without me getting any say in it.

You can always re-open a report.

See, I'm just arguing that in 90% of cases we'd not get any feedback (or
not in time), so the cron job would kick in. In 9% of cases, people would
use a recent snapshot and report the problem fixed. This needs human
interaction then to close the PR for good.  In 1% of cases, people would
realize that the bug is not fixed at all and complain. We need to do
something in that case anyway.

If we just didn't have the third state, we would only have to do something 
in this 1% of cases, not in the 10%. I don't see any difference from a QA 
viewpoint between having the third state and closing fixed PRs with the 
note
  "The bug is fixed now. We would appreciate if you could check this and 
   let us know if you still have problems."
Except for the fact that the last point creates significant less work for 
us all.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[DJ Delorie]

In the cases you're talking about, the cron job would automatically
close the PR shortly after it's fixed.  This doesn't require extra
people at all.

In the cases I'm talking about, the originator would have a window of
opportunity to test the fix and reject it if it doesn't happen to fix
it for them.  I've been burned too many times with my bug reports (er,
not gcc, but for other projects) being closed without being fixed, and
without me getting any say in it.

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

> I think it would be better to have some automatic VERIFIED->CLOSED
> cron job, which gives the originator N weeks to reject the fix.

We get the majority of reports against _releases_, not snapshots. If 
something's fixed in a snapshot, it might be half a year or more until the 
originator get's to check whether the bug is fixed. I also get the 
impression that most people just use what's on their system, and then it 
might be even longer until she upgrades.

Asking the originator for confirmation that a bug is fixed is plain 
impractical.

I see us dreaming up complicated schemes to make use of the three-state
thing in bugzilla. I would really like that people keep in mind the cost
of maintaining it. Please, everyone, we should realize that we're not
Microsoft that can throw 100 people at a problem. We just don't have them
and I personally will not have the time to close bugs in a two-step
process. I can make much better use of my time, and I also have the
impression that bugzilla has a lot of places where I can spend it on more 
useful things that following an overly complicated workflow.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[DJ Delorie]

I think it would be better to have some automatic VERIFIED->CLOSED
cron job, which gives the originator N weeks to reject the fix.

Re: your RESOLVED->CLOSED changes

[DJ Delorie]

Just my two cents and IMHO, but...

There should be one state that means "the developer thinks it's fixed"
and one just after it that means "the originator agrees."  I don't
like the idea of the originator closing bug reports without
confirmation from the originator.  I.e. the developer does verified
and resolved, but the originator moves resolved cases to closed.

There should be one closed state that means "closed without fixing
anything" and one that means "fixed".

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

> > 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. :-)

But that's the whole point. We got into the problem of having 2000 open
reports at one point in time exactly because those people with obscure
platforms didn't check into the database. I see no reason to believe that
this has changed. If we ask them to do that, nothing's going to happen and
these PRs will stay in VERIFIED forever. Let's just be pragmatic and say
that we don't have the resources to do anything better than our testsuite,
and let's drop 2 of the 3 states. If at one point we have the resources,
we can still add it again and start to use it with release N+1.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

> I can make VERIFIED and CLOSED options invisible to the user, so that 
> you don't ever see it, if you like.

That would be nice. I don't care whether the state we use is called CLOSED 
or RESOLVED, but one state is enough (it seems the majority agrees with 
that).

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[Daniel Berlin]

On Friday, May 23, 2003, at 10:37  AM, Volker Reichelt wrote:

> On 23 May, 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.
>>
>> 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?
>
> Full Ack!
>
> We've got more than 1600 open PRs. And we introduce a lot of bugs
> with each new major release (although this seems to get better).
> So I don't mind the couple of bugs slipping through the cracks of
> the testsuite. They will be found like all the other bugs were
> found. Having two states or more for closed bugs just wastes
> resources that we need for managing the bug database and
> confused the users IMHO.

Okay guys, let me see if i can clear a few things up:
1. There is no need to mark bugs closed, actually, unless you want to 
do QA. This can be viewed as mistake on my part during conversion, 
mapping GNATS's closed to CLOSED rather than RESOLVED.
2. Bugs with states CLOSED, RESOLVED, and VERIFIED are considered 
closed bugs.
This is actually coded into Bugzilla (The reason i haven't removed 
VERIFIED and CLOSED is because it would make for a bunch of merge 
conflicts whenever i import new bugzilla sources).

sub OpenStates {
     return ('NEW', 'REOPENED', 'SUSPENDED', 'WAITING', 'ASSIGNED', 
$::unconfirmedstate);
}
$vars->{'closedstates'} = ['CLOSED', 'VERIFIED', 'RESOLVED'];


I can make VERIFIED and CLOSED options invisible to the user, so that 
you don't ever see it, if you like.  Making RESOLVED invisible, or 
changing it's name, is harder, though possible.

You can leave things resolved, rather than closed, and the world will 
not end.

>
> Regards,
> Volker
>
>

Re: your RESOLVED->CLOSED changes

[Nathanael Nerode]

Daniel Berlin wrote:
> Because it gets mail when you close/resolve bugs, and when you add 
Given the presence of 'closed' *and* 'resolved' states, this is 
redundant, sadly. :-/

> However, admins can always do it another few ways that you can't:
> The trivial way is to edit the gcc-bugs user to have a known password 
> (it's a random string of characters so that nobody screws with it), 
> which requires admin privileges, log in as gcc-bugs, and make the batch 
> changes from gcc-bugs.
> gcc-bugs won't get mail about it's own changes (it's a preference, so it 
> can be changed, but shouldn't).
Cute. :-)

Re: your RESOLVED->CLOSED changes

[Nathanael Nerode]

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. :-)

Re: your RESOLVED->CLOSED changes

[Nathanael Nerode]

Giovanni Bajo wrote:
> Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> 
> 
>>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 don't think it's your "fault", because this is exactly what Bugzilla lets
> you do right now. I'm doing the same as well right now.  It's not such a big
> issue because we have so many bugs in RESOLVED status, so a batch change is
> needed anyway, somewhere in the future.
> 
> Right now, in order to change to CLOSED, you need to edit the bug two times,
> and this is suboptimal. If we agree for removing the distinction, we'll
> surely ask Danny to update the system accordingly (the best way is to modify
> the commit actions so that they immediatly switch to the CLOSED status
> instead of switching to the RESOLVED status).

If we keep 'verified' (as I suggested), I would still approve of this. 
The commit actions would have "Close, setting resolution to X" and 
"Verify fixed (but not in a release), setting resolution to X".

The "resolved" state is not useful in the long run to a project with no 
separate QA team.

> Giovanni Bajo

Re: your RESOLVED->CLOSED changes

[Nathanael Nerode]

Giovanni Bajo wrote:
> 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?

Well, there was a pair which were each closed as "duplicates" of the 
other one. :-)  That's a sort of human error, but it's also 
script-catchable.

There was another one which I'm guessing was in a somewhat bogus state 
in GNATS (which allowed some strange combinations).  The last message 
was on the order of "I think this is invalid, could someone check?", so 
it wasn't supposed to be closed.

There were also a couple marked as duplicates of other bugs for unknown 
reasons, since they weren't; in one case, someone had said "I think this 
is a duplicate of #x" and someone else had said "No, it isn't."

 >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
Yes, it is.  When a user reports a bug which is fixed on mainline we can 
say "Dupe of bug xxx, will be fixed in the next version."

It also makes for an easier way to get a list of bugs "fixed in this 
version" for each release; one can just run through the 'verified' bugs 
looking for the fixed ones.  Of course, there would have to be a mass 
run-through (and closure of most) 'verified' bugs around the time of 
each release.  One could probably close all which were fixed before the 
release branch en masse and generate a list of fixed bugs automatically 
from that.

 >for users which rarely greps in the bug database before submitting, 
and >not among closed bugs anyway.
Well, they should. :-)  And maybe we could change the default search for 
users to search 'verified' bugs as well as open bugs?

 >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.
OK, that sounds like an excellent idea.

--Nathanael

Re: your RESOLVED->CLOSED changes

[Volker Reichelt]

On 23 May, 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.
> 
> 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?

Full Ack!

We've got more than 1600 open PRs. And we introduce a lot of bugs
with each new major release (although this seems to get better).
So I don't mind the couple of bugs slipping through the cracks of
the testsuite. They will be found like all the other bugs were
found. Having two states or more for closed bugs just wastes
resources that we need for managing the bug database and
confused the users IMHO.

Regards,
Volker

Re: your RESOLVED->CLOSED changes

[Daniel Berlin]

On Friday, May 23, 2003, at 03:18  AM, Nathanael Nerode 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. :-/
>
> 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).

Because it gets mail when you close/resolve bugs, and when you add 
comments, as the posted the email preferences for gcc-bugs stated.
Thus, poking bugs with adding comments will generate mail.

The add comments part is necessary to make sure discussion posted to 
gcc-bugzilla gets back to the list, and emailing gcc-bugzilla is 
necessary to make sure discussion gets added to the bug.
The rest is emulating existing behavior, i thought.

>  And for that matter, if there
> are privileges you have to avoid this that I don't, why that is. :-/
>  I've
> poked large numbers of bugs in one day in the past as a matter of
> routine maintenance, sorting, correcting.

Actually, unless i'm mistaken, they can do it but don't realize how.  
Mass changes with comments would still send out mail, I *think*. i'm 
not positive. I can make it not send out mail, but it'll probably take 
a few tries
to get right.  The logic for this part is a bit convoluted.

However, admins can always do it another few ways that you can't:
The trivial way is to edit the gcc-bugs user to have a known password 
(it's a random string of characters so that nobody screws with it), 
which requires admin privileges, log in as gcc-bugs, and make the batch 
changes from gcc-bugs.
gcc-bugs won't get mail about it's own changes (it's a preference, so 
it can be changed, but shouldn't).

Another way is to temporarily change gcc-bugs email preferences, and 
then do it from any account, then change them back.  I'd rather people 
not do this, however.

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

>> 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?
>
> Doesn't that prove the lack of QA, and demonstrate the need for it? If a 
> fix hasn't been checked, it *should* remain resolved-but-unclosed 
> indefinately until someone checks it. Otherwise, why bother checking 
> fixes at all?

Yes and no. Yes, because in a sense you're right but it's just a fact that 
we're developer starved and don't have enough people working on the rarer 
platforms.

No, since at least in principle each patch should go in with a testcase, 
so the very same developer will re-check every time he runs the testsuite.
The initial check whether a patch is sane is done by peer review.

W.


-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[John Anthony Kazos Jr.]

>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?

Doesn't that prove the lack of QA, and demonstrate the need for it? If a 
fix hasn't been checked, it *should* remain resolved-but-unclosed 
indefinately until someone checks it. Otherwise, why bother checking fixes 
at all? 

Re: your RESOLVED->CLOSED changes

[Wolfgang Bangerth]

> 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.

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?

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: your RESOLVED->CLOSED changes

[Giovanni Bajo]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> 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 don't think it's your "fault", because this is exactly what Bugzilla lets
you do right now. I'm doing the same as well right now.  It's not such a big
issue because we have so many bugs in RESOLVED status, so a batch change is
needed anyway, somewhere in the future.

Right now, in order to change to CLOSED, you need to edit the bug two times,
and this is suboptimal. If we agree for removing the distinction, we'll
surely ask Danny to update the system accordingly (the best way is to modify
the commit actions so that they immediatly switch to the CLOSED status
instead of switching to the RESOLVED status).

Giovanni Bajo

Re: your RESOLVED->CLOSED changes

[John Anthony Kazos Jr.]

>On Fri, 23 May 2003, Nathanael Nerode wrote:
>
> > >Besides, we were discussing the whole VERIFIED/RESOLVED/CLOSED issue
> > >off-list (and once we would have found an agreement among ourselves, we
> > >were going to bring the issue on the list of course). Theoretically,
> > >nobody
> > Honestly, better to discuss this one on-list.  Probably better to have
> > discussed it before the switchover, as well, but that's water under the
> > bridge.
>
>The distinction *was* discussed before the conversion - I raised several
>times the question of whether we needed that VERIFIED/RESOLVED/CLOSED
>distinction, though no conclusion may have been reached.

I suggest:

VERIFIED - It really is a bug, and it is being (or will be) worked on.
RESOLVED - A fix has been created, and now is being tested.
CLOSED - The fix is tested and determined to be good; bug eliminated.

Ii desu masu ne? 

Re: your RESOLVED->CLOSED changes

[Joseph S. Myers]

On Fri, 23 May 2003, Nathanael Nerode wrote:

> >Besides, we were discussing the whole VERIFIED/RESOLVED/CLOSED issue
> >off-list (and once we would have found an agreement among ourselves, we 
> >were going to bring the issue on the list of course). Theoretically, 
> >nobody
> Honestly, better to discuss this one on-list.  Probably better to have 
> discussed it before the switchover, as well, but that's water under the 
> bridge.

The distinction *was* discussed before the conversion - I raised several
times the question of whether we needed that VERIFIED/RESOLVED/CLOSED
distinction, though no conclusion may have been reached.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: your RESOLVED->CLOSED changes

[Gerald Pfeifer]

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/

Re: your RESOLVED->CLOSED changes

[Giovanni Bajo]

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

Re: your RESOLVED->CLOSED changes

[Nathanael Nerode]

>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. :-/

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).  And for that matter, if there
are privileges you have to avoid this that I don't, why that is. :-/  I've
poked large numbers of bugs in one day in the past as a matter of 
routine maintenance, sorting, correcting.

>Besides, we were discussing the whole VERIFIED/RESOLVED/CLOSED issue
>off-list (and once we would have found an agreement among ourselves, we 
>were going to bring the issue on the list of course). Theoretically, 
>nobody
Honestly, better to discuss this one on-list.  Probably better to have 
discussed it before the switchover, as well, but that's water under the 
bridge.

>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.)

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).

--Nathanael