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