public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gerald Pfeifer <gerald@pfeifer.com>
To: Richard Guenther <rguenther@suse.de>
Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org,
	Jakub Jelinek <jakub@redhat.com>,
	     "Joseph S. Myers" <joseph@codesourcery.com>,
	     Mark Mitchell <mark@codesourcery.com>
Subject: Re: [PATCH] Adjust develop.html to reflect recent practice
Date: Sun, 27 Sep 2009 06:23:00 -0000	[thread overview]
Message-ID: <alpine.LSU.1.99.0909270020480.899@acrux.dbai.tuwien.ac.at> (raw)
In-Reply-To: <alpine.LNX.2.00.0909201433140.4520@zhemvz.fhfr.qr>

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>
 

  parent reply	other threads:[~2009-09-26 22:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-20 12:35 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 [this message]
2009-09-27 19:17   ` Richard Guenther
2009-10-04 18:52     ` Gerald Pfeifer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.1.99.0909270020480.899@acrux.dbai.tuwien.ac.at \
    --to=gerald@pfeifer.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=mark@codesourcery.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).