[PATCH] Adjust develop.html to reflect recent practice

[Richard Guenther <rguenther@suse.de>]

As commented to my last status report develop.html does not reflect
reality anymore.  The following tries to adjust it carefully in
this respect.

Ok for www?

Thanks,
Richard.

2009-09-20  Richard Guenther  <rguenther@suse.de>

	* develop.html: Adjust to reflect recent practice.

Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.100
diff -u -r1.100 develop.html
--- develop.html	4 Aug 2009 22:36:39 -0000	1.100
+++ develop.html	20 Sep 2009 12:32:39 -0000
@@ -38,7 +38,7 @@
 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 the
+<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>
 
@@ -102,37 +102,35 @@
 
 <h3>Schedule</h3>
 
-<p>Development on our main branch will proceed in three stages.  Each
-stage will be two months in length.</p>
+<p>Development on our main branch will proceed in three stages.</p>
 
 <h4><a name="stage1">Stage 1</a></h4>
 
 <p>During this period, changes of any nature may be made to the
 compiler.  In particular, major changes may be merged from branches.
-In order to avoid chaos, the Release Manager will ask for a list of
+Stage 1 and its length is feature driven and its length will be
+at least four month.
+In order to avoid chaos, the Release Managers will ask for a list of
 major projects proposed for the coming release cycle before the start
-of Stage 1.  The Release Manager will attempt to sequence the projects
-in such a way as to cause minimal disruption.  The Release Manager
+of Stage 1.  The Release Managers will attempt to sequence the projects
+in such a way as to cause minimal disruption.  The Release Managers
 will not reject projects that will be ready for inclusion before the
-end of Stage 1.  Similarly, the Release Manager has no special power
-to accept a particular patch or branch beyond what his or her status
-as a maintainer affords.  The Release Manager's role during Stage 1 is
+end of Stage 1.  Similarly, the Release Managers have no special power
+to accept a particular patch or branch beyond what their status
+as maintainers affords.  The Release Managers role during Stage 1 is
 merely to attempt to order the inclusion of major features in an
 organized manner.</p>
 
 <h4><a name="stage2">Stage 2</a></h4>
 
-<p>During this period, major changes may not be merged from branches.
-However, other smaller improvements may be made.  For example, support
-for a new language construct might be added in a front-end, or support
-for a new variant of an existing microprocessor might be added to a
-back-end.</p>
+<p>Stage 2 has been abandoned in favor of an extended feature driven
+Stage 1 since the development of GCC 4.4.</p>
 
 <h4><a name="stage3">Stage 3</a></h4>
 
-<p>During this period, the only (non-documentation) changes that may be
-made are changes that fix bugs or new ports which do not require changes
-to other parts of the compiler.
+<p>During this two-month period, the only (non-documentation) changes
+that may be made are changes that fix bugs or new ports which do not
+require changes to other parts of the compiler.
 New functionality may not be introduced during this period.</p>
 
 <p><strong>Rationale</strong></p>
@@ -143,13 +141,14 @@
 cycle, so that we have time to fix any problems that result.</p>
 
 <p>In order to reach higher standards of quality, we must focus on
-fixing bugs; by working exclusively on bug-fixing through Stage 3, we
-will have a higher quality source base as we prepare for a release.</p>
+fixing bugs; by working exclusively on bug-fixing through Stage 3
+and before branching for the release, we will have a higher quality
+source base as we prepare for a release.</p>
 
 <p>Although maintaining a development branch, including merging new
 changes from the mainline, is somewhat burdensome, the absolute worst
-case is that such a branch will have to be maintained for four months.
-During two of those months, the only mainline changes will be bug-fixes,
+case is that such a branch will have to be maintained for six months.
+During this period, the only mainline changes will be bug-fixes,
 so it is unlikely that many conflicts will occur.</p>
 
 
@@ -203,20 +202,17 @@
 
 <h3>Schedule</h3>
 
-<p>At the conclusion of Stage 3, a release branch will be created.</p>
-
-<p>On the release branch, the focus will be fixing any regressions
+<p>At the conclusion of Stage 3, the trunk will go into release branch
+mode which allows documentation and regression fixes only.
+During this phase, the focus will be fixing any regressions
 from the previous release, so that each release is better than the one
 before.</p>
 
-<p>The release will occur two months after the creation of the branch.
-(Stage 1 of the next release cycle will occur in parallel.)  If,
-however, support for an important platform has regressed significantly
-from the previous release or support for a platform with active
-maintenance has regressed significantly relative to an earlier Stage
-in the current release cycle, the release will be postponed until the
-regressions are corrected, unless the Steering Committee releases the
-automatic hold on the release.</p>
+<p>At the point the trunk is in a state suitable for releasing
+a release branch will be created, a release candidate is made available
+and Stage 1 of the next release cycle starts.
+The decision on when this point is reached is up to the Release Managers.
+In particular at this point no P1 regressions are present on the trunk.</p>
 
 <p><strong>Rationale</strong></p>
 
@@ -224,7 +220,7 @@
 be subordinate to schedule.  If a major platform is not adequately
 supported, but was well supported in a previous release, then we
 should address the problems.  Presumably, this will not be unduly
-difficult, since we will have spent four months fixing bugs by the
+difficult, since we will have spent at least two months fixing bugs by the
 time the release would occur.</p>