This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missing explanation of Stage 4 in GCC Development Plan document


On Tue, Apr 28, 2015 at 7:01 AM, Thomas Preud'homme
<thomas.preudhomme@arm.com> wrote:
>> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.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.

Richard.

>
>>
>> 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.
>
> 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,
>
> Thomas
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]