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: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: "James Greenhalgh" <James dot Greenhalgh at arm dot com>, "Richard Biener" <richard dot guenther at gmail dot com>
- Cc: "GCC Development" <gcc at gcc dot gnu dot org>
- Date: Tue, 28 Apr 2015 13:01:38 +0800
- 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> <20150427154834 dot GA1093 at arm dot com>
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of James Greenhalgh
> 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).
Don't stage3 and stage4 differ in that substantial changes are still allowed
for backends in stage3?
> 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
> 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.
If we keep referring to stages in our communication it would be nice to
document them. I'm not saying this rewording is wrong, I just think we
should add 1-2 sentences to explain the stages (I know it confused me
at first because stage4 was not listed). Alternatively we could just
refer to these 2 names only (development and stabilization).