[PATCH docs] remove Java from GCC 7 release criteria

Richard Biener rguenther@suse.de
Fri Mar 3 08:55:00 GMT 2017


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 <msebor@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 <law@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.



More information about the Gcc-patches mailing list