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: Richard Biener <richard dot guenther at gmail dot com>
- To: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- Cc: James Greenhalgh <James dot Greenhalgh at arm dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 28 Apr 2015 12:49:39 +0200
- 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> <000b01d08170$6ac06ba0$404142e0$ at arm dot com>
On Tue, Apr 28, 2015 at 7:01 AM, Thomas Preud'homme
>> From: email@example.com [mailto:firstname.lastname@example.org] On
>> Behalf Of James Greenhalgh
> Hi James,
>> 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?
stage3 is for _general_ bugfixing while stage4 is for _regression_ bugfixing.
>> 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).
> Best regards,