On Thu, 2 Mar 2017, Martin Sebor wrote: > On 03/02/2017 12:58 AM, Richard Biener wrote: > > On Wed, 1 Mar 2017, Martin Sebor wrote: > > > > > On 02/28/2017 11:41 PM, Richard Biener wrote: > > > > On March 1, 2017 3:34:46 AM GMT+01:00, Martin Sebor <mse...@gmail.com> > > > > wrote: > > > > > On 02/28/2017 01:41 PM, Richard Biener wrote: > > > > > > On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law > > > > > > <l...@redhat.com> > > > > > wrote: > > > > > > > On 02/28/2017 10:54 AM, Martin Sebor wrote: > > > > > > > > The GCC 7 release criteria page mentions Java even though > > > > > > > > the front end has been removed. The attached patch removes Java > > > > > > > > from the criteria page. While reviewing the rest of the text I > > > > > > > > noticed a few minor typos that I corrected in the patch as well. > > > > > > > > > > > > > > > > Btw., as an aside, I read the page to see if I could find out > > > > > > > > more > > > > > > > > about the "magic" bug counts that are being aimed for to decide > > > > > when > > > > > > > > to cut the release. Can someone say what those are and where to > > > > > > > > find them? I understand from the document that they're not > > > > > > > > exact > > > > > > > > but even ballpark numbers would be useful. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > WRT the bug counts. 0 P1 regressions, < 100 P1-P3 regressions. > > > > > > > I'm > > > > > > > not > > > > > > > sure if that's documented anywhere though. > > > > > > > > > > > > Actually the only criteria is zero P1 regressions. Those are > > > > > documented to block a release. > > > > > > > > > > Yes, that is mentioned in the document. Would it be fair to say > > > > > that the number of P2 bugs (or regressions) or their nature plays > > > > > into the decision in some way as well? If so, what can the release > > > > > criteria say about it? > > > > > > > > Ultimatively P2 bugs do not play a role and 'time' will trump them. > > > > OTOH we > > > > never were in an uncomfortable situation with P2s at the desired point > > > > of > > > > release. > > > > > > > > Also note that important P2 bugs can be promoted to P1 and not important > > > > P1 > > > > to P2. > > > > > > > > > I'm trying to get a better idea which bugs to work on and where > > > > > my help might have the biggest impact. I think having better > > > > > visibility into the bug triage process (such as bug priorities > > > > > and how they impact the release schedule) might help others > > > > > focus too. > > > > > > > > In order of importance: > > > > - P1 > > > > - wrong-code, rejects-valid, ice-on-valid (even if not regressions, > > > > regressions more important) > > > > - P2 regressions, more recent ones first (newest working version) > > > > > > I see. This is helpful, thanks. > > > > > > The kinds of problems you mention are discussed in the document > > > so just to make the importance clear, would adding the following > > > after this sentence > > > > > > In general bugs blocking the release are marked with priority P1 > > > (Maintaining the GCC Bugzilla database). > > > > > > accurately reflect what you described? > > > > > > As a general rule of thumb, within each priority level, bugs that > > > result in incorrect code are considered more urgent than those > > > that lead to rejecting valid code, which in turn are viewed as > > > more severe than ice-on-valid code (compiler crashes). More > > > recently reported bugs are also prioritized over very old ones. > > > > I'd rather see to clarify things in bugs/management.html. Note > > that wrong-code, rejects-valid, ice-on-valid are equally important. > > Less important would be accepts-invalid or ice-on-invalid or, of course, > > missed-optimization. Also it's not more recently _reported_ bugs > > but a [6/7 Regression] is more important to fix than a [5/6/7 Regression] > > (this is also why [7 Regression]s are P1 by default). > > Got it. Attached is a rewording of the paragraph above added to > bugs/management.html. I put it under the Importance (Severity > and Priority) heading but it could probably fit just as well under > Procedures and Policies. > > Please let me know if there's anything else that can be said to > further clarify things, or if you have any other suggestions.
Looks fine! Thus, ok. Richard.
