On Mon, Apr 27, 2015 at 09:37:36AM +0100, Richard Biener wrote: > On Sun, Apr 26, 2015 at 9:56 AM, Honggyu Kim <hong.gyu....@lge.com> wrote: > > Hi all, > > > > I would like to know about the stages of development plan so I checked the > > following article: > > https://gcc.gnu.org/develop.html
[Just Bike-shedding...] 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). In which case, we seem only to be keeping the process listed as an aspiration, rather than a document of reality. 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. Thanks, James
