I'd going to make a change to the policy for setting priorities for PRs in Bugzilla, to try to help address two issues that have been raised:
1. There may be vitally important bugs that are not regressions, and therefore do not get visibility before releases. (We have, in past, allowed changes on release branches for things like building the Linux kernel, even though they were not regressions.) 2. There may be regressions that appear more important to me than they really are. (In particular, people have mentioned optimization regressions: some of these may be unaavoidable consequences of improvements.) There's also a meta-issue: I don't want to be a bottleneck, for this or other aspects of GCC development. So, I'm going to make a few adjustments to the prioritization policy, effective immediately: 1. If you think that a PR deserves P1/P2 status (but doesn't have it) and you are a maintainer of the affected part of the compiler, please mark the issue as P3, add a note to the issue explaining why you think it should have higher priority, and CC: me. My default reaction will probably be to deprioritize the issue -- especially if there's no patch -- so make a good case. 2. If you think that a P2 PR should be taken off the radar, and you are a maintainer of the affected part of the compiler, you may downgrade it to P4 at will. 3. If you think that a P1 PR should be downgraded, and you are a maintainer of the affected part of the compiler, please add a note to the issue explaining why, and CC: me. The reason for the "maintainer of the affected part of the compiler" language above is that I will not be able to handle a stream of such requests coming from all over the place. I also want to give authority and responsibility to the various maintainers. So, if you're not a maintainer, but you want to make one of the changes above, lobby a maintainer. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
