* Re: Classifying bugs
@ 2004-01-12 15:08 Wolfgang Bangerth
0 siblings, 0 replies; 13+ messages in thread
From: Wolfgang Bangerth @ 2004-01-12 15:08 UTC (permalink / raw)
To: gcc; +Cc: Gabriel Dos Reis, Andrew Pinski
> The recent thread on the GCC-3.4.0 has lead some "bug masters" to
> either downgrade or close some PRs on the ground that they think they
> should not be blocking.
>
> While I understand that they are doing what they think is good
> for "clearing the road" for 3.4.0, I do not agree with the general
> trend of closing/downgrading as many as PRs as possible just to make
> to it look as if they were very few bugs. In particular, such actions
> should be conducted under clear guidance from the appropriate Release
> Manager. A Release Manager may decide to ship even if there were some
> high priority bugs; they need not be downgraded first.
I agree with this, and I disagree with many of the decisions to downgrade
bug reports. We have discussed this before on the bugzilla-masters mailing
list and have reached a conclusion that has not been followed by one
person. I would like to ask him to revisit the bugs he has changed and use
proper judgment to revert some of these decisions. Arguments like "this is
only a 2.95 regression", or "performance regressions should not block the
branch" are not valid reasons to move milestones.
Since this is not the first time he has not followed our rules, I would
also like to ask him to be extra-careful in the futue when applying
personal judgment rather than technical criteria when changing fields in
bugzilla.
Thanks
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Classifying bugs
2004-01-12 15:21 S. Bosscher
@ 2004-01-12 15:28 ` Wolfgang Bangerth
0 siblings, 0 replies; 13+ messages in thread
From: Wolfgang Bangerth @ 2004-01-12 15:28 UTC (permalink / raw)
To: S. Bosscher
Cc: 'gcc@gcc.gnu.org ', 'Gabriel Dos Reis ',
'Andrew Pinski '
> Why was this policy not discussed on gcc@, or at least announced?
That may well have been a deficiency. We have a private mailing list for
bugzilla people where we discuss some policies in case there are
questions. We discussed this particular questions there (with said person
being subscribed to it), and I had discussed this with him in private mail
before as well.
> I do not agree with all downgradings, but I disagree even more with
> the ease with which some bugmasters assign a target milestone. If
> you want to be so strict about all this, then you should discuss
> every milestone with the RM.
Indeed.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Classifying bugs
@ 2004-01-12 15:21 S. Bosscher
2004-01-12 15:28 ` Wolfgang Bangerth
0 siblings, 1 reply; 13+ messages in thread
From: S. Bosscher @ 2004-01-12 15:21 UTC (permalink / raw)
To: 'Wolfgang Bangerth ', 'gcc@gcc.gnu.org '
Cc: 'Gabriel Dos Reis ', 'Andrew Pinski '
> Since this is not the first time he has not followed our rules, I would
> also like to ask him to be extra-careful in the futue when applying
> personal judgment rather than technical criteria when changing fields in
> bugzilla.
Why was this policy not discussed on gcc@, or at least announced?
I do not agree with all downgradings, but I disagree even more with
the ease with which some bugmasters assign a target milestone. If
you want to be so strict about all this, then you should discuss
every milestone with the RM.
Gr.
Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Classifying bugs
2004-01-12 6:52 Gabriel Dos Reis
2004-01-12 8:34 ` Arnaud Charlet
2004-01-12 10:52 ` Giovanni Bajo
@ 2004-01-12 14:48 ` Andrew Haley
2 siblings, 0 replies; 13+ messages in thread
From: Andrew Haley @ 2004-01-12 14:48 UTC (permalink / raw)
To: gcc
Gabriel Dos Reis writes:
>
> Hi,
>
> The recent thread on the GCC-3.4.0 has lead some "bug masters" to
> either downgrade or close some PRs on the ground that they think they
> should not be blocking.
>
> While I understand that they are doing what they think is good
> for "clearing the road" for 3.4.0, I do not agree with the general
> trend of closing/downgrading as many as PRs as possible just to make
> to it look as if they were very few bugs. In particular, such actions
> should be conducted under clear guidance from the appropriate Release
> Manager. A Release Manager may decide to ship even if there were some
> high priority bugs; they need not be downgraded first.
In particular, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12419 has
had its severity downgraded. Okay, so it's only a performance
regression, but it hits gcj (and, I suppose, g++) where it hurts
badly: method dispatch.
Andrew.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 10:55 ` Giovanni Bajo
@ 2004-01-12 14:09 ` Gabriel Dos Reis
0 siblings, 0 replies; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-01-12 14:09 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: Steven Bosscher, Arnaud Charlet, gcc
"Giovanni Bajo" <giovannibajo@libero.it> writes:
| Steven Bosscher wrote:
|
| > And yes, I believe the bug masters can say if a bug is significant
| > or not. If they can not, then they shouldn't have permission to be
| > bug masters.
|
| Yes, we can say if it's significant by changing its severity, or
Hmm, I'm not sure I abide by that game. Any other comments?
-- Gaby
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 9:11 ` Steven Bosscher
@ 2004-01-12 10:55 ` Giovanni Bajo
2004-01-12 14:09 ` Gabriel Dos Reis
0 siblings, 1 reply; 13+ messages in thread
From: Giovanni Bajo @ 2004-01-12 10:55 UTC (permalink / raw)
To: Steven Bosscher, Gabriel Dos Reis, Arnaud Charlet; +Cc: gcc
Steven Bosscher wrote:
> And yes, I believe the bug masters can say if a bug is significant
> or not. If they can not, then they shouldn't have permission to be
> bug masters.
Yes, we can say if it's significant by changing its severity, or stating in the
logs that it'ss an useless bug, or remembering that it was working only in 2.95
and never worked in 3.x releases (so probably people don't care that much).
They are all very sensitive things to do, but it's RM's job to decide if it
must be fixed for the next release or not, unless he gives us some explicit
written policy about how to behave in certain special cases.
Giovanni Bajo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 6:52 Gabriel Dos Reis
2004-01-12 8:34 ` Arnaud Charlet
@ 2004-01-12 10:52 ` Giovanni Bajo
2004-01-12 14:48 ` Andrew Haley
2 siblings, 0 replies; 13+ messages in thread
From: Giovanni Bajo @ 2004-01-12 10:52 UTC (permalink / raw)
To: gcc, Gabriel Dos Reis
Gabriel Dos Reis wrote:
> The recent thread on the GCC-3.4.0 has lead some "bug masters" to
> either downgrade or close some PRs on the ground that they think they
> should not be blocking.
>
> While I understand that they are doing what they think is good
> for "clearing the road" for 3.4.0, I do not agree with the general
> trend of closing/downgrading as many as PRs as possible just to make
> to it look as if they were very few bugs. In particular, such actions
> should be conducted under clear guidance from the appropriate Release
> Manager. A Release Manager may decide to ship even if there were some
> high priority bugs; they need not be downgraded first.
I totally agree.
Giovanni Bajo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 9:06 ` Gabriel Dos Reis
@ 2004-01-12 9:11 ` Steven Bosscher
2004-01-12 10:55 ` Giovanni Bajo
0 siblings, 1 reply; 13+ messages in thread
From: Steven Bosscher @ 2004-01-12 9:11 UTC (permalink / raw)
To: Gabriel Dos Reis, Arnaud Charlet; +Cc: gcc
On Monday 12 January 2004 10:00, Gabriel Dos Reis wrote:
> | > From the audit trails that prompted my comment, I have not seen that
> | > scenario being "many".
> |
> | Aren't you are basing your judgement on an 'after the fact' basis,
> | meaning that you are only taking into account actualy changes of
> | priorities that brought your attention.
>
> As my original message said, I'm basing my comments on the recent
> recategorization on the ground of "clearing the road" for 3.4.0.
There always has been clearing of the road, but as you correctly
point out, the RM should take care of this. But the number of PRs
was so large at one point that it would be unreasonable to ask of
Mark to go through them all. I don't think it is a problem then if
the same people who set the priorities in the first place now take
the responsibility to re-set them so that the RM can get a picture
of how the next GCC compares with previous releases without wading
through enhancement requests and insignificant bugs.
And yes, I believe the bug masters can say if a bug is significant
or not. If they can not, then they shouldn't have permission to be
bug masters.
Gr.
Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 8:48 ` Arnaud Charlet
@ 2004-01-12 9:06 ` Gabriel Dos Reis
2004-01-12 9:11 ` Steven Bosscher
0 siblings, 1 reply; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-01-12 9:06 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: gcc
Arnaud Charlet <charlet@ACT-Europe.FR> writes:
| > Many bugs?
|
| Yes, from my experience with e.g. Ada PRs, many PRs have either a wrong priority
| or wrong dependencies making PRs look like they are dependent on others
| and blocking all of them while this is not necessary. I guess the latter
| is probably Ada specific because people are not very familiar with how
| things work, but the former looks more like a general trend.
Peobably, there is something about how Ada maintainers have dealt with
Ada-related PRs in the past; but I would not generalize that to other
components.
| I'd say that around 50% of the PRs I have dealt with had to be
| recategorized/reprioritized.
|
| > From the audit trails that prompted my comment, I have not seen that
| > scenario being "many".
|
| Aren't you are basing your judgement on an 'after the fact' basis, meaning
| that you are only taking into account actualy changes of priorities that
| brought your attention.
As my original message said, I'm basing my comments on the recent
recategorization on the ground of "clearing the road" for 3.4.0.
| I'd guess there are still many PRs wrongly
| categorized simply because people do not have the time to correct them.
PRs get recategorized as people get more and more understanding of
them. I was not talking of that.
-- Gaby
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 8:40 ` Gabriel Dos Reis
@ 2004-01-12 8:48 ` Arnaud Charlet
2004-01-12 9:06 ` Gabriel Dos Reis
0 siblings, 1 reply; 13+ messages in thread
From: Arnaud Charlet @ 2004-01-12 8:48 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Arnaud Charlet, gcc
> Many bugs?
Yes, from my experience with e.g. Ada PRs, many PRs have either a wrong priority
or wrong dependencies making PRs look like they are dependent on others
and blocking all of them while this is not necessary. I guess the latter
is probably Ada specific because people are not very familiar with how
things work, but the former looks more like a general trend.
I'd say that around 50% of the PRs I have dealt with had to be
recategorized/reprioritized.
> From the audit trails that prompted my comment, I have not seen that
> scenario being "many".
Aren't you are basing your judgement on an 'after the fact' basis, meaning
that you are only taking into account actualy changes of priorities that
brought your attention. I'd guess there are still many PRs wrongly
categorized simply because people do not have the time to correct them.
Arno
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 8:34 ` Arnaud Charlet
@ 2004-01-12 8:40 ` Gabriel Dos Reis
2004-01-12 8:48 ` Arnaud Charlet
0 siblings, 1 reply; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-01-12 8:40 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: gcc
Arnaud Charlet <charlet@ACT-Europe.FR> writes:
| > While I understand that they are doing what they think is good
| > for "clearing the road" for 3.4.0, I do not agree with the general
| > trend of closing/downgrading as many as PRs as possible just to make
| > to it look as if they were very few bugs. In particular, such actions
| > should be conducted under clear guidance from the appropriate Release
| > Manager. A Release Manager may decide to ship even if there were some
| > high priority bugs; they need not be downgraded first.
|
| I generally agree with this comment.
| On the other hand, you have to consider what is happening in reality
| for many bugs: the reporter of a bug typically considers /his/ problem
Many bugs?
| blocking, while this is very typically not the case and affects only
| very specific options or very specific sequence of actions. Not even
| talking about other subtleties such as regression/vs non regression, etc...
From the audit trails that prompted my comment, I have not seen that
scenario being "many".
-- Gaby
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Classifying bugs
2004-01-12 6:52 Gabriel Dos Reis
@ 2004-01-12 8:34 ` Arnaud Charlet
2004-01-12 8:40 ` Gabriel Dos Reis
2004-01-12 10:52 ` Giovanni Bajo
2004-01-12 14:48 ` Andrew Haley
2 siblings, 1 reply; 13+ messages in thread
From: Arnaud Charlet @ 2004-01-12 8:34 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc
> While I understand that they are doing what they think is good
> for "clearing the road" for 3.4.0, I do not agree with the general
> trend of closing/downgrading as many as PRs as possible just to make
> to it look as if they were very few bugs. In particular, such actions
> should be conducted under clear guidance from the appropriate Release
> Manager. A Release Manager may decide to ship even if there were some
> high priority bugs; they need not be downgraded first.
I generally agree with this comment.
On the other hand, you have to consider what is happening in reality
for many bugs: the reporter of a bug typically considers /his/ problem
blocking, while this is very typically not the case and affects only
very specific options or very specific sequence of actions. Not even
talking about other subtleties such as regression/vs non regression, etc...
Arno
^ permalink raw reply [flat|nested] 13+ messages in thread
* Classifying bugs
@ 2004-01-12 6:52 Gabriel Dos Reis
2004-01-12 8:34 ` Arnaud Charlet
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-01-12 6:52 UTC (permalink / raw)
To: gcc
Hi,
The recent thread on the GCC-3.4.0 has lead some "bug masters" to
either downgrade or close some PRs on the ground that they think they
should not be blocking.
While I understand that they are doing what they think is good
for "clearing the road" for 3.4.0, I do not agree with the general
trend of closing/downgrading as many as PRs as possible just to make
to it look as if they were very few bugs. In particular, such actions
should be conducted under clear guidance from the appropriate Release
Manager. A Release Manager may decide to ship even if there were some
high priority bugs; they need not be downgraded first.
My two cents,
-- Gaby
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-01-12 15:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-12 15:08 Classifying bugs Wolfgang Bangerth
-- strict thread matches above, loose matches on Subject: below --
2004-01-12 15:21 S. Bosscher
2004-01-12 15:28 ` Wolfgang Bangerth
2004-01-12 6:52 Gabriel Dos Reis
2004-01-12 8:34 ` Arnaud Charlet
2004-01-12 8:40 ` Gabriel Dos Reis
2004-01-12 8:48 ` Arnaud Charlet
2004-01-12 9:06 ` Gabriel Dos Reis
2004-01-12 9:11 ` Steven Bosscher
2004-01-12 10:55 ` Giovanni Bajo
2004-01-12 14:09 ` Gabriel Dos Reis
2004-01-12 10:52 ` Giovanni Bajo
2004-01-12 14:48 ` Andrew Haley
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).