[PATCH docs] remove Java from GCC 7 release criteria

[PATCH docs] remove Java from GCC 7 release criteria

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

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.

Thanks
Martin

[-- Attachment #2: gcc-7-criteria.diff --]
[-- Type: text/x-patch, Size: 3887 bytes --]

Index: criteria.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/criteria.html,v
retrieving revision 1.1
diff -u -r1.1 criteria.html
--- criteria.html	23 May 2016 09:16:41 -0000	1.1
+++ criteria.html	28 Feb 2017 17:41:00 -0000
@@ -7,7 +7,7 @@
 
 <h1>GCC 7 Release Criteria</h1>
 
-<p>This page provides the release criteria for GCC 7.</p>  
+<p>This page provides the release criteria for GCC 7.</p>
 
 <p>The GCC team (and, in particular, the Release Managers) will attempt
 to meet these criteria before the release of GCC 7.</p>
@@ -18,7 +18,7 @@
 candidate will probably not become the eventual release.  However, a
 release candidate that does meet these criteria may not necessarily
 become the official release; there may be other unforeseen issues that
-prevent release.  For example, if support for the Intel Pentium II is
+prevent the release.  For example, if support for the Intel Pentium II is
 required by the release criteria, it is nevertheless unlikely that GCC
 would be released even though it did not support the Intel Pentium.</p>
 
@@ -32,10 +32,10 @@
 <h1>Languages</h1>
 
 <p>GCC supports several programming languages, including Ada, C, C++,
-Fortran, Objective-C, Objective-C++, Go and Java.
+Fortran, Objective-C, Objective-C++, and Go.
 For the purposes of making releases,
 however, we will consider primarily C and C++, as those are the
-languages used by the vast majority of users.  Therefore, if, below,
+languages used by the vast majority of users.  Therefore, if below
 the criteria indicate, for example, that there should be no DejaGNU
 regressions on a particular platform, that criteria should be read as
 applying only to DejaGNU regressions within the C, C++, and C++
@@ -53,12 +53,12 @@
 All platforms that are neither primary nor secondary are tertiary
 platforms.</p>
 
-<p>Our release criteria for primary platforms is:</p>
+<p>Our release criteria for primary platforms are:</p>
 <ul>
 
 <li>
 <p>All regressions open in Bugzilla have been analyzed, and all are
-deemed as either unlikely to affect most users, or are determined to
+deemed either unlikely to affect most users, or are determined to
 have a minimal impact on affected users.  For example, a
 typographical error in a diagnostic might be relatively common, but
 also has minimal impact on users.</p>
@@ -67,14 +67,14 @@
 code, or refuses to compile a valid program, will be considered to
 be sufficiently severe to block the release, unless there are
 substantial mitigating factors.</p>
-</li>  
+</li>
 
 <li>The DejaGNU testsuite has been run, and compared with a run of
 the testsuite on the previous release of GCC, and no regressions are
 observed.</li>
 </ul>
 
-<p>Our release criteria for the secondary platforms is:</p>
+<p>Our release criteria for the secondary platforms are:</p>
 <ul>
 <li>The compiler bootstraps successfully, and the C++ runtime library
 builds.</li>
@@ -92,7 +92,7 @@
 explicit application testing.  It is our experience that, with the
 resources available, it is very difficult to methodically carry out
 such testing. However, we expect that interested users will submit
-bug reports for problems encountered building and using popular
+bug reports for problems encountered while building and using popular
 packages.  Therefore, we do not intend the elimination of application
 testing from our criteria to imply that we will not pay attention to
 application testing.</p>
@@ -142,7 +142,7 @@
 superior code on other test cases.  Therefore, the Release Manager, or
 parties to whom he or she delegates responsibility, will make
 determinations on a case-by-case basis as to whether or not a code
-quality or compilation time regression is sufficiently severe as to
+quality or compilation time regression is sufficiently severe to
 merit blocking the release.</p>
 
 </body>

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

[Jeff Law]

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.

jeff

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

[Martin Sebor]

On 02/28/2017 11:00 AM, Jeff Law 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.

Thanks.  Would it make sense to mention these numbers in the criteria?
E.g., like so (assuming those apply to primary platforms):

-<p>Our release criteria for primary platforms is:</p>
+<p>Our release criteria for primary platforms are:</p>
  <ul>

  <li>
+<p>No open P1 regressions in Bugzilla and no more than 100 open P2
+and P3 regressions.</p>
+</li>
+
+<li>

Martin

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

[Jeff Law]

On 02/28/2017 11:09 AM, Martin Sebor wrote:
> On 02/28/2017 11:00 AM, Jeff Law 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.
>
> Thanks.  Would it make sense to mention these numbers in the criteria?
> E.g., like so (assuming those apply to primary platforms):
For non-primary platforms BZs get put into the P4/P5 priority buckets, 
so it's a non-issue.

OK.

jeff

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

[Richard Biener]

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.

Richard.

>jeff

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

[Martin Sebor]

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?

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.

Martin

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

[Richard Biener]

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

>Martin

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

[Gerald Pfeifer]

On Tue, 28 Feb 2017, 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.

Thanks, Martin!

To minor comments:

-bug reports for problems encountered building and using popular
+bug reports for problems encountered while building and using popular

I believe the original version was fine (an is shorter), so personally
would have left it as is.  Your proposed one is correct, too, of course.

-quality or compilation time regression is sufficiently severe as to
+quality or compilation time regression is sufficiently severe to
 merit blocking the release.</p>

Same here, though here I like yours edit better. :-)

Gerald

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

[Martin Sebor]

On 03/01/2017 08:08 AM, Gerald Pfeifer wrote:
> On Tue, 28 Feb 2017, 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.
>
> Thanks, Martin!
>
> To minor comments:
>
> -bug reports for problems encountered building and using popular
> +bug reports for problems encountered while building and using popular
>
> I believe the original version was fine (an is shorter), so personally
> would have left it as is.  Your proposed one is correct, too, of course.
>
> -quality or compilation time regression is sufficiently severe as to
> +quality or compilation time regression is sufficiently severe to
> merit blocking the release.</p>
>
> Same here, though here I like yours edit better. :-)

Thanks for the review!

I committed the first patch for now (without the P1/P2 numbers).
If there's consensus to add something more about those than what's
already there I'll post a new patch to add that.

Martin

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

[Martin Sebor]

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.

Martin

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

[Richard Biener]

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)

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

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 3834 bytes --]

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.

Martin

[-- Attachment #2: gcc-bug-management.diff --]
[-- Type: text/x-patch, Size: 2006 bytes --]

Index: management.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.31
diff -u -r1.31 management.html
--- management.html	29 Jun 2014 11:31:33 -0000	1.31
+++ management.html	2 Mar 2017 22:35:00 -0000
@@ -56,6 +56,8 @@
 <p>Bugzilla offers a number of different fields.  From a maintainer's
 perspective, these are the relevant ones and what their values mean:</p>
 
+<h3><a name="status">Status</a></h3>
+
 The status and resolution fields define and track the life cycle of a
 bug.  In addition to their <a
 href="https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html">regular
@@ -77,9 +79,10 @@
 
 </dl>
 
+<h3><a name="importance">Importance (Severity and Priority)</a></h3>
 
 <p>The following two fields describe how serious a bug is from a user's
-perspective (severity) and which priority we assign to it in fixing it:</p>
+perspective (Severity) and what Priority we assign to it in fixing it:</p>
 
 <table border="1" cellpadding="4"><tr>
 <td valign="top">
@@ -140,6 +143,18 @@
 </td></tr>
 </table>
 
+<p>As a general rule of thumb, within each priority level, bugs that result
+in incorrect code (keyword <i>wrong-code</i>) are considered equally as important
+to fix as those that lead to rejecting valid code (<i>rejects-valid</i>) and as
+those that cause an ICE for valid code (<i>ice-on-valid-code</i>).  Lower in
+importance, however, are <i>accepts-invalid</i> and <i>ice-on-invalid</i> bugs,
+and less important still are <i>missed-optimization</i> opportunities.</p>
+
+<p>Regressions that only affect more recent releases are prioritized over those
+that also affect older releases.  For example, prior to the release of GCC 7,
+a regression that was introduced in GCC 6 and that affects GCC 7 is considered
+more important to fix in  GCC 7 than a regression that was introduced in GCC 5
+(and is still present in GCC 6 and 7).</p>
 
 <h3><a name="assigned_to">Assigned To</a></h3>
 

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

[Richard Biener]

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.