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

Reply via email to