Re: [PATCH docs] remove Java from GCC 7 release criteria

[Richard Biener <rguenther at suse dot de>]

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).

Richard.

> Martin
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)