Re: Error on the development plan web page?

[Phil Edwards <phil at jaj dot com>]

While cleaning out old mail, and maintaining this thread's tradition
of one reply per month, I came across:

On Fri, Oct 04, 2002 at 05:09:45PM +0200, Gerald Pfeifer wrote:
> On Fri, 13 Sep 2002, Erik Schnetter wrote:
> > The web page http://gcc.gnu.org/develop.html, which contains the GCC
> > Development plan, has in the third paragraph of the section
> > "Development Methodology / Schedule / Rationale" the text
> >
> > "[...] a branch will have to be maintained for four months. During two
> > of those months, the only mainline changes will be bug-fixes [...]"
> >
> > I do not see how this follows from the previous text (and the text
> > further down in the section "Release Methodology").  It seems to me
> > that the release branch would have to be maintained for six months,
> > because releases are scheduled every six months.
> 
> I'm a bit astonished that nobody has replied to this yet, but I believe
> there is a misunderstanding: "branch", in that part of the document,
> refers to development branches (such as the new C++ parser) not release
> branches.
> 
> You are right in that release branches usually will have to be maintained
> for (at least) six months.
> 
> 
> Perhaps we should differentiate between "development branches" and
> "release branches"?  Opinions?

That sounds useful.  How about this?


Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.21
diff -u -3 -r1.21 develop.html
--- develop.html	14 Oct 2002 19:49:47 -0000	1.21
+++ develop.html	7 Nov 2002 07:22:29 -0000
@@ -61,7 +61,7 @@
 guidance on the GCC mailing lists.  In general, a change that has the
 potential to be extremely destabilizing should be done on a branch.</p>
 
-<p>Changes may be merged from a branch only after:</p>
+<p>Changes may be merged from a development branch only after:</p>
 
 <ul>
 <li>They meet the standards for any other check-in.  For example, the
@@ -130,11 +130,11 @@
 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>
 
-<p>Although maintaining a 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, so it is
-unlikely that many conflicts will occur.</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,
+so it is unlikely that many conflicts will occur.</p>
 
 
 <h3>Patch Reversion</h3>
@@ -163,7 +163,7 @@
 the development of other improvements.</p>
 
 <p>On the other hand, we want to encourage new development, and new
-development inevitable introduces new bugs.  Therefore, it is
+development inevitably introduces new bugs.  Therefore, it is
 important that decisions be made on a case-by-case basis, and that the
 proponent of a change have an opportunity to argue that the benefits
 of the change outweigh the costs.  Therefore, the decision to revert