* Re: your RESOLVED->CLOSED changes
@ 2003-05-23 15:29 Volker Reichelt
2003-05-23 16:18 ` Daniel Berlin
0 siblings, 1 reply; 24+ messages in thread
From: Volker Reichelt @ 2003-05-23 15:29 UTC (permalink / raw)
To: bangerth
Cc: giovannibajo, pfeifer, neroden, ehrhardt, ebotcazou, gcc, dberlin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 15:29 your RESOLVED->CLOSED changes Volker Reichelt
@ 2003-05-23 16:18 ` Daniel Berlin
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:37 ` DJ Delorie
0 siblings, 2 replies; 24+ messages in thread
From: Daniel Berlin @ 2003-05-23 16:18 UTC (permalink / raw)
To: Volker Reichelt
Cc: bangerth, giovannibajo, pfeifer, neroden, ehrhardt, ebotcazou, gcc
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
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 16:18 ` Daniel Berlin
@ 2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:37 ` DJ Delorie
1 sibling, 0 replies; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 19:23 UTC (permalink / raw)
To: Daniel Berlin
Cc: Volker Reichelt, giovannibajo, pfeifer, neroden, ehrhardt,
ebotcazou, gcc
> 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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 16:18 ` Daniel Berlin
2003-05-23 19:23 ` Wolfgang Bangerth
@ 2003-05-23 19:37 ` DJ Delorie
1 sibling, 0 replies; 24+ messages in thread
From: DJ Delorie @ 2003-05-23 19:37 UTC (permalink / raw)
To: dberlin; +Cc: gcc
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".
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 20:03 ` DJ Delorie
@ 2003-05-23 20:14 ` Wolfgang Bangerth
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 20:14 UTC (permalink / raw)
To: DJ Delorie; +Cc: neroden, gcc
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 19:56 ` Wolfgang Bangerth
@ 2003-05-23 20:03 ` DJ Delorie
2003-05-23 20:14 ` Wolfgang Bangerth
0 siblings, 1 reply; 24+ messages in thread
From: DJ Delorie @ 2003-05-23 20:03 UTC (permalink / raw)
To: bangerth; +Cc: neroden, gcc
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 19:46 ` DJ Delorie
@ 2003-05-23 19:56 ` Wolfgang Bangerth
2003-05-23 20:03 ` DJ Delorie
0 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 19:56 UTC (permalink / raw)
To: DJ Delorie; +Cc: neroden, gcc
> 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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 19:23 ` Wolfgang Bangerth
@ 2003-05-23 19:46 ` DJ Delorie
2003-05-23 19:56 ` Wolfgang Bangerth
0 siblings, 1 reply; 24+ messages in thread
From: DJ Delorie @ 2003-05-23 19:46 UTC (permalink / raw)
To: bangerth; +Cc: neroden, gcc
I think it would be better to have some automatic VERIFIED->CLOSED
cron job, which gives the originator N weeks to reject the fix.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 15:47 ` Nathanael Nerode
@ 2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:46 ` DJ Delorie
0 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 19:23 UTC (permalink / raw)
To: Nathanael Nerode; +Cc: gcc
> > 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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 15:05 ` Daniel Berlin
@ 2003-05-23 15:54 ` Nathanael Nerode
0 siblings, 0 replies; 24+ messages in thread
From: Nathanael Nerode @ 2003-05-23 15:54 UTC (permalink / raw)
To: Daniel Berlin, gcc
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. :-)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 14:18 ` Wolfgang Bangerth
@ 2003-05-23 15:47 ` Nathanael Nerode
2003-05-23 19:23 ` Wolfgang Bangerth
0 siblings, 1 reply; 24+ messages in thread
From: Nathanael Nerode @ 2003-05-23 15:47 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc
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. :-)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 14:18 ` Wolfgang Bangerth
[not found] ` <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utex as.edu>
@ 2003-05-23 15:41 ` Nathanael Nerode
2 siblings, 0 replies; 24+ messages in thread
From: Nathanael Nerode @ 2003-05-23 15:41 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 8:55 ` Giovanni Bajo
2003-05-23 9:36 ` Gerald Pfeifer
@ 2003-05-23 15:33 ` Nathanael Nerode
1 sibling, 0 replies; 24+ messages in thread
From: Nathanael Nerode @ 2003-05-23 15:33 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 7:39 Nathanael Nerode
` (2 preceding siblings ...)
[not found] ` <Pine.LNX.4.53.0305231035220.4682@kern.srcf.societies.cam.a c.uk>
@ 2003-05-23 15:05 ` Daniel Berlin
2003-05-23 15:54 ` Nathanael Nerode
3 siblings, 1 reply; 24+ messages in thread
From: Daniel Berlin @ 2003-05-23 15:05 UTC (permalink / raw)
To: Nathanael Nerode; +Cc: giovannibajo, gcc
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
@ 2003-05-23 14:55 Wolfgang Bangerth
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 14:55 UTC (permalink / raw)
To: John Anthony Kazos Jr.; +Cc: gcc
>> 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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
[not found] ` <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utex as.edu>
@ 2003-05-23 14:19 ` John Anthony Kazos Jr.
0 siblings, 0 replies; 24+ messages in thread
From: John Anthony Kazos Jr. @ 2003-05-23 14:19 UTC (permalink / raw)
To: gcc
>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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 10:19 ` Giovanni Bajo
@ 2003-05-23 14:18 ` Wolfgang Bangerth
2003-05-23 15:47 ` Nathanael Nerode
[not found] ` <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utex as.edu>
2003-05-23 15:41 ` Nathanael Nerode
2 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Bangerth @ 2003-05-23 14:18 UTC (permalink / raw)
To: Giovanni Bajo
Cc: Gerald Pfeifer, Nathanael Nerode, Volker Reichelt,
Christian Ehrhardt, ebotcazou, gcc, dberlin
> 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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 9:36 ` Gerald Pfeifer
@ 2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 14:18 ` Wolfgang Bangerth
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Giovanni Bajo @ 2003-05-23 10:19 UTC (permalink / raw)
To: Gerald Pfeifer
Cc: Nathanael Nerode, Wolfgang Bangerth, Volker Reichelt,
Christian Ehrhardt, ebotcazou, gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
[not found] ` <Pine.LNX.4.53.0305231035220.4682@kern.srcf.societies.cam.a c.uk>
@ 2003-05-23 9:53 ` John Anthony Kazos Jr.
0 siblings, 0 replies; 24+ messages in thread
From: John Anthony Kazos Jr. @ 2003-05-23 9:53 UTC (permalink / raw)
To: gcc
>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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 7:39 Nathanael Nerode
2003-05-23 8:55 ` Giovanni Bajo
@ 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 15:05 ` Daniel Berlin
3 siblings, 0 replies; 24+ messages in thread
From: Joseph S. Myers @ 2003-05-23 9:43 UTC (permalink / raw)
To: Nathanael Nerode; +Cc: giovannibajo, gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 8:55 ` Giovanni Bajo
@ 2003-05-23 9:36 ` Gerald Pfeifer
2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 15:33 ` Nathanael Nerode
1 sibling, 1 reply; 24+ messages in thread
From: Gerald Pfeifer @ 2003-05-23 9:36 UTC (permalink / raw)
To: Giovanni Bajo
Cc: Nathanael Nerode, Wolfgang Bangerth, Volker Reichelt,
Christian Ehrhardt, ebotcazou, gcc
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
2003-05-23 7:39 Nathanael Nerode
@ 2003-05-23 8:55 ` Giovanni Bajo
2003-05-23 9:36 ` Gerald Pfeifer
2003-05-23 15:33 ` Nathanael Nerode
2003-05-23 9:43 ` Joseph S. Myers
` (2 subsequent siblings)
3 siblings, 2 replies; 24+ messages in thread
From: Giovanni Bajo @ 2003-05-23 8:55 UTC (permalink / raw)
To: Nathanael Nerode
Cc: Wolfgang Bangerth, Volker Reichelt, Christian Ehrhardt, ebotcazou, gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: your RESOLVED->CLOSED changes
@ 2003-05-23 7:39 Nathanael Nerode
2003-05-23 8:55 ` Giovanni Bajo
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Nathanael Nerode @ 2003-05-23 7:39 UTC (permalink / raw)
To: giovannibajo; +Cc: gcc
>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
^ permalink raw reply [flat|nested] 24+ messages in thread
* your RESOLVED->CLOSED changes
[not found] <20030523062858.322.qmail@sources.redhat.com>
@ 2003-05-23 6:59 ` Giovanni Bajo
0 siblings, 0 replies; 24+ messages in thread
From: Giovanni Bajo @ 2003-05-23 6:59 UTC (permalink / raw)
To: neroden; +Cc: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-05-23 20:12 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-23 15:29 your RESOLVED->CLOSED changes Volker Reichelt
2003-05-23 16:18 ` Daniel Berlin
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:37 ` DJ Delorie
-- strict thread matches above, loose matches on Subject: below --
2003-05-23 14:55 Wolfgang Bangerth
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
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
[not found] <20030523062858.322.qmail@sources.redhat.com>
2003-05-23 6:59 ` Giovanni Bajo
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).