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