This is the mail archive of the
mailing list for the GCC project.
Re: missing explanation of Stage 4 in GCC Development Plan document
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 27 Apr 2015 16:48:35 +0100
- Subject: Re: missing explanation of Stage 4 in GCC Development Plan document
- Authentication-results: sourceware.org; auth=none
- References: <00aa01d07ff6$85108880$8f319980$ at lge dot com> <CAFiYyc2==yhVKZEUVtzzoj3ENiGx1vfhcww6hv669LW-==56pg at mail dot gmail dot com>
On Mon, Apr 27, 2015 at 09:37:36AM +0100, Richard Biener wrote:
> On Sun, Apr 26, 2015 at 9:56 AM, Honggyu Kim <email@example.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
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)?
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.
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.