Mark Mitchell wrote:
When I mark a PR as "P1", that means "This is a regression, and I think
it's embarrassing for us, as a community, to have this bug in a
release." Unfortunately, every release goes out with P1 bugs open, so
we can't really call them "release blockers". My judgment isn't always
great, and it's certainly not final: I'm willing for people to suggest
that P1s be downgraded. I've suggested that people do that by putting a
note in the PR, and CC'ing me.
OK, thanks for clarifying that. Are the P1s the only thing you consider
when deciding whether or not to make a release?
I agree that PR32252 (the example given by Jason) should not be P1.
I've downgraded it to P2. (P2 means "regression users will notice on a
major platform, but not P1". P3 means "not yet looked at". Things like
ICE-after-valid-error are marked P4. Things utterly outside the release
criteria are P5.)
How do non-regressions fit into this scheme?
One of the consistent problems with GCC has been that we disregard the
experience of users that aren't power users. However, I disagree that
these things should be extremely low priority. Compiler ICEs send
message that what we're producing is not of high quality so I think we
should take them seriously.
Absolutely. But not as seriously as wrong-code or
ice-on-valid/rejects-valid bugs, IMO.
I do also think we should start weeding out some of the P2s that have
been around a long time. If GCC 2.95 didn't ICE, but GCC 3.0+ have all
ICE'd, then, at this point, it's not much of a regression any more; it's
just an ICE that's "always" been there.
Yes.
I do think that we should take regressions, in general, very seriously
-- especially cases where we generate wrong code. One of the consistent
complaints I have heard is that people fear GCC upgrades and the
perception is that this is worse than with other compilers. Certainly,
I've talked to other compiler vendors who claim that they consider any
wrong-code generation bug a release blocker.
I absolutely agree for regressions on valid code. But regressions on
invalid code, or on valid code that we've never accepted, shouldn't
affect people upgrading. That's the distinction I want to make.
Now, all that said, of course I think that other bugs are important too,
and I'm all for fixing them. But, in terms of looking at a release and
deciding how ready-to-go it is, I think regressions are as reasonable a
measure as any.
I think the term "critical regressions" you've used in past status
updates (wrong-code, ice-on-valid-code, rejects-valid regressions) are a
good measure, but not other regressions; non-critical regressions should
not have higher priority than serious non-regression bugs. We have had
a bunch of C++ wrong-code bugs hanging around for a long time, and I
don't think ice-on-invalid-code regressions should take priority over those.
I was thinking of a default priority scheme like
new/uncategorized bugs are P0.
critical regressions from the previous release series are P1.
other critical regressions and wrong-code bugs are P2.
non-critical regressions and ice-on-valid-code/rejects-valid bugs are P3.
most other bugs are P4.
enhancements are P5.
adjusting priorities up or down based on how often the bug is
encountered, or how much work it is to fix.
Jason
