* [PATCH] Adjust develop.html to reflect recent practice
@ 2009-09-20 12:35 Richard Guenther
2009-09-20 13:58 ` Dave Korn
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Richard Guenther @ 2009-09-20 12:35 UTC (permalink / raw)
To: gcc; +Cc: gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-20 12:35 [PATCH] Adjust develop.html to reflect recent practice Richard Guenther
@ 2009-09-20 13:58 ` Dave Korn
2009-09-20 16:30 ` Mark Mitchell
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Dave Korn @ 2009-09-20 13:58 UTC (permalink / raw)
To: Richard Guenther
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
Richard Guenther wrote:
> * develop.html: Adjust to reflect recent practice.
TYVM :)
cheers,
DaveK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-20 12:35 [PATCH] Adjust develop.html to reflect recent practice Richard Guenther
2009-09-20 13:58 ` Dave Korn
@ 2009-09-20 16:30 ` Mark Mitchell
2009-09-20 19:40 ` Theodore Papadopoulo
2009-09-27 6:23 ` Gerald Pfeifer
3 siblings, 0 replies; 8+ messages in thread
From: Mark Mitchell @ 2009-09-20 16:30 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers
Richard Guenther wrote:
> 2009-09-20 Richard Guenther <rguenther@suse.de>
>
> * develop.html: Adjust to reflect recent practice.
OK.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-20 12:35 [PATCH] Adjust develop.html to reflect recent practice Richard Guenther
2009-09-20 13:58 ` Dave Korn
2009-09-20 16:30 ` Mark Mitchell
@ 2009-09-20 19:40 ` Theodore Papadopoulo
2009-09-20 19:50 ` Richard Guenther
2009-09-27 6:23 ` Gerald Pfeifer
3 siblings, 1 reply; 8+ messages in thread
From: Theodore Papadopoulo @ 2009-09-20 19:40 UTC (permalink / raw)
To: Richard Guenther
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
Richard Guenther wrote:
> As commented to my last status report develop.html does not reflect
> reality anymore. The following tries to adjust it carefully in
> this respect.
>
>
> <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>
Just a minor tweak...
Since there are only effectively two stages, wouldn't it be better to
state two stages here ?
Theo.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-20 19:40 ` Theodore Papadopoulo
@ 2009-09-20 19:50 ` Richard Guenther
0 siblings, 0 replies; 8+ messages in thread
From: Richard Guenther @ 2009-09-20 19:50 UTC (permalink / raw)
To: Theodore Papadopoulo
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
On Sun, 20 Sep 2009, Theodore Papadopoulo wrote:
> Richard Guenther wrote:
> > As commented to my last status report develop.html does not reflect
> > reality anymore. The following tries to adjust it carefully in
> > this respect.
> >
> > <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>
> Just a minor tweak...
> Since there are only effectively two stages, wouldn't it be better to state
> two stages here ?
Effectively after leaving Stage 3 we enter a "Stage 4" before the
release branch is created. So all, two, three and four would be
in some way correct ;) Thus I didn't bother to change this detail.
Richard.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-20 12:35 [PATCH] Adjust develop.html to reflect recent practice Richard Guenther
` (2 preceding siblings ...)
2009-09-20 19:40 ` Theodore Papadopoulo
@ 2009-09-27 6:23 ` Gerald Pfeifer
2009-09-27 19:17 ` Richard Guenther
3 siblings, 1 reply; 8+ messages in thread
From: Gerald Pfeifer @ 2009-09-27 6:23 UTC (permalink / raw)
To: Richard Guenther
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
On Sun, 20 Sep 2009, Richard Guenther wrote:
> As commented to my last status report develop.html does not reflect
> reality anymore. The following tries to adjust it carefully in
> this respect.
I believe you got the math wrong in one case, when you went from
four months that a branch will need to be maintained in the old
model up to six months. Is it possible you ment to substract the
two months Stage 2 used to take instead of add it?
Since it seems hard to predicat the time between the end of Stage 3
and branching, I suggest to just say "a few months".
The patch below does that in its last hunk and makes one or the
other editorial change.
Thoughts?
Gerald
Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.101
diff -u -3 -p -r1.101 develop.html
--- develop.html 20 Sep 2009 19:50:27 -0000 1.101
+++ develop.html 26 Sep 2009 22:21:10 -0000
@@ -108,17 +108,16 @@ well), then we can seriously confuse use
<p>During this period, changes of any nature may be made to the
compiler. In particular, major changes may be merged from branches.
-Stage 1 and its length is feature driven and its length will be
-at least four month.
+Stage 1 is feature driven and will last at least four months.
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 Managers will attempt to sequence the projects
+of Stage 1. They 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 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
+as maintainers affords. The role of the Release Managers 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>
@@ -147,7 +146,7 @@ source base as we prepare for a release.
<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 six months.
+case is that such a branch will have to be maintained for a few months.
During this period, the only mainline changes will be bug-fixes,
so it is unlikely that many conflicts will occur.</p>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-27 6:23 ` Gerald Pfeifer
@ 2009-09-27 19:17 ` Richard Guenther
2009-10-04 18:52 ` Gerald Pfeifer
0 siblings, 1 reply; 8+ messages in thread
From: Richard Guenther @ 2009-09-27 19:17 UTC (permalink / raw)
To: Gerald Pfeifer
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
On Sun, 27 Sep 2009, Gerald Pfeifer wrote:
> On Sun, 20 Sep 2009, Richard Guenther wrote:
> > As commented to my last status report develop.html does not reflect
> > reality anymore. The following tries to adjust it carefully in
> > this respect.
>
> I believe you got the math wrong in one case, when you went from
> four months that a branch will need to be maintained in the old
> model up to six months. Is it possible you ment to substract the
> two months Stage 2 used to take instead of add it?
Indeed, I mixed in the length of stage1. Four month would be
still about correct (2 month stage3 plus 2 month before we branch,
in the old model it was 2 month stage2 plus 2 month stage3).
> Since it seems hard to predicat the time between the end of Stage 3
> and branching, I suggest to just say "a few months".
>
> The patch below does that in its last hunk and makes one or the
> other editorial change.
>
> Thoughts?
Ok with me.
Thanks,
Richard.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Adjust develop.html to reflect recent practice
2009-09-27 19:17 ` Richard Guenther
@ 2009-10-04 18:52 ` Gerald Pfeifer
0 siblings, 0 replies; 8+ messages in thread
From: Gerald Pfeifer @ 2009-10-04 18:52 UTC (permalink / raw)
To: Richard Guenther
Cc: gcc, gcc-patches, Jakub Jelinek, Joseph S. Myers, Mark Mitchell
On Sun, 27 Sep 2009, Richard Guenther wrote:
> Ok with me.
Applied now.
Gerald
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-10-04 18:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-20 12:35 [PATCH] Adjust develop.html to reflect recent practice Richard Guenther
2009-09-20 13:58 ` Dave Korn
2009-09-20 16:30 ` Mark Mitchell
2009-09-20 19:40 ` Theodore Papadopoulo
2009-09-20 19:50 ` Richard Guenther
2009-09-27 6:23 ` Gerald Pfeifer
2009-09-27 19:17 ` Richard Guenther
2009-10-04 18:52 ` Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).