Jason Merrill wrote: > 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".
> OK, thanks for clarifying that. Are the P1s the only thing you consider > when deciding whether or not to make a release? Roughly speaking, yes. Of course, if someone were to raise an issue with me in some other way, then I would consider that too. But, generally, I look at the open P1s to determine whether or not quality is at an acceptable level. >> 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? They don't. Historically (well, as long as I can remember), anything that was a non-regression was automatically P5. That's not to say that there are no important non-regression bugs. But, my feeling has been that if the bug was not a regression, then we've had a demonstrably useful compiler up until now, so it wasn't something that I needed to worry about for the next release. >> 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. Totally agreed. In theory, the "cost" of a bug is some product-like function of its prevalence (i.e., the number of people who run into it) and its severity (i.e., the impact it has on those that encounter it). I do try to make that judgment in some cases: if I see a bug that looks unlikely to affect anyone in the real world, then I might not mark it P1, even though it's a wrong-code regression. But, prevalence is hard to measure, so, in general, I mark wrong-code regressions as P1. > 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. That's a fair point and that's why I downgraded the issue you mentioned from P1 to P2. > 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 think we need to agree on what the priority scheme is for. In a commercial setting, we might have bug-killing droids who came in each morning, picked the highest priority bug off the list, and zapped it. But, we don't -- we have people who pick whatever is of interest to them. So, I've used the priority scheme as a way to tell me how well we're doing relative to the previous release. In other words, I'm not trying to suggest that if you want to maximize goodness of the compiler you pick the highest priority bug and fix it. Then again, if you fix a P1, you're probably doing a good thing. When we run out of P1s, come see me. :-) We can fight over whether to work on the P2s, or something else. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
