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


> 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?


> 
> 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]