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). Richard. > Martin > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
