From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3199 invoked by alias); 20 Sep 2009 12:35:05 -0000 Received: (qmail 3180 invoked by uid 22791); 20 Sep 2009 12:35:04 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Sep 2009 12:35:00 +0000 Received: from relay2.suse.de (relay-ext.suse.de [195.135.221.8]) by mx2.suse.de (Postfix) with ESMTP id 92B8D8726A; Sun, 20 Sep 2009 14:34:57 +0200 (CEST) Date: Sun, 20 Sep 2009 12:35:00 -0000 From: Richard Guenther To: gcc@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek , "Joseph S. Myers" , Mark Mitchell Subject: [PATCH] Adjust develop.html to reflect recent practice Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00378.txt.bz2 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 * 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.

-

In addition, a consistent schedule will make it possible for the +

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.

@@ -102,37 +102,35 @@

Schedule

-

Development on our main branch will proceed in three stages. Each -stage will be two months in length.

+

Development on our main branch will proceed in three stages.

Stage 1

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.

Stage 2

-

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.

+

Stage 2 has been abandoned in favor of an extended feature driven +Stage 1 since the development of GCC 4.4.

Stage 3

-

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. +

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.

Rationale

@@ -143,13 +141,14 @@ cycle, so that we have time to fix any problems that result.

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.

+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.

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.

@@ -203,20 +202,17 @@

Schedule

-

At the conclusion of Stage 3, a release branch will be created.

- -

On the release branch, the focus will be fixing any regressions +

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.

-

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.

+

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.

Rationale

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