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 <rguent...@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>
