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