missing explanation of Stage 4 in GCC Development Plan document

[James Greenhalgh]

On Mon, Apr 27, 2015 at 09:37:36AM +0100, Richard Biener wrote:
> On Sun, Apr 26, 2015 at 9:56 AM, Honggyu Kim <hong.gyu.kim@lge.com> wrote:
> > Hi all,
> >
> > I would like to know about the stages of development plan so I checked the following article:
> > https://gcc.gnu.org/develop.html

[Just Bike-shedding...]

The stages, timings, and exact rules for which patches are acceptable
and when, seem to have drifted quite substantially from that page.
Stage 2 has been missing for 7 years now, Stages 3 and 4 seem to blur
together, the "regression only" rule is more like "non-invasive fixes
only" (likewise for the support branches).

In which case, we seem only to be keeping the process listed as an
aspiration, rather than a document of reality.

So, why not try to reflect practice and form a two stage model (and
name the stages in a descriptive fashion)?

  Development:

  Expected to last for around 70% of a release cycle. 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 Managers will ask for a list of major projects proposed for
  the coming release cycle before the start of this stage. 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 the development phase. Similarly,
  the Release Managers have no special power to accept a particular
  patch or branch beyond what their status as maintainers affords.
  The role of the Release Managers is merely to attempt to order the
  inclusion of major features in an organized manner.

  Stabilization:

  Expected to last for around 30% of a release cycle. New functionality
  may not be introduced during this period. Changes during this phase
  of the release cycle should focus on preparing the trunk for a high
  quality release, free of major regression and code generation issues.
  As we near the end of a release cycle, changes will only be accepted
  where they fix a regression, or are sufficiently non-intrusive as to
  not introduce a risk of affecting the quality of the release.

Thanks,
James