diff mbox

[wwwdocs] Shorten rationale for development plan

Message ID alpine.LNX.2.00.1202121954350.5509@gerinyyl.fvgr
State New
Headers show

Commit Message

Gerald Pfeifer Feb. 12, 2012, 7:40 p.m. UTC
This was totally suitable for when it was written; us now having
had this in place for ages and approaching GCC 4.7, make this a
bit shorter, by about a fourth, and make the context in time more
explicit.

Applied.

Gerald
diff mbox

Patch

Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.120
diff -u -3 -p -r1.120 develop.html
--- develop.html	2 Jan 2012 11:52:41 -0000	1.120
+++ develop.html	12 Feb 2012 18:50:55 -0000
@@ -26,21 +26,16 @@  rejected by the <a href="steering.html">
 
 <p><strong>Rationale</strong></p>
 
-<p>It has been difficult for us to make consistent, high-quality
-releases that support a wide variety of targets.  In particular, GCC
-3.0 achieved a high standard of quality on many targets, but was by no
-means perfect, and failed to support as many targets as we would have
-liked.</p>
-
-<p>In addition, the release was late relative to original scheduling
-estimates.  And, the time between the GCC 2.95 and GCC 3.0 releases
-was longer than everyone would have liked.  We think that we will
-better serve the user community by making releases somewhat more
-frequently, and on a consistent schedule.</p>
-
-<p>In addition, a consistent schedule will make it possible for a
-Release Manager to better understand his or her time commitment will
-be when he or she agrees to take the job.</p>
+<p>Late in the GCC 2.x series and then GCC 3.x we struggled making
+consistent, high-quality releases for as wide a variety of targets
+as we would have liked.  GCC 3.0 came late relative to original
+scheduling estimates and the time between the GCC 2.95 and GCC 3.0
+releases was longer than everyone would have liked.</p>
+
+<p>We think that more frequent releases on a consistent schedule
+serve our user communities better.  In addition, a consistent schedule
+makes it possible for Release Managers to better understand what they
+are signing up for.</p>
 
 
 <h2>Development Methodology</h2>