On Tue, Oct 23, 2007 at 02:20:24PM -0400, 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". 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?
I would like to see more attention paid to wrong-code bugs that aren't marked as "regression". Doesn't mean they should necessarily be P1, but we tend to ignore them.