GCC Development Plan - GNU Project - Free Software Foundation (FSF)
gcc@gcc.gnu.org gcc-h...@gcc.gnu.org Pook
Re: missing explanation of Stage 4 in GCC Development Plan document
On Mon, Oct 19, 2015 at 3:41 AM, Gerald Pfeifer wrote: > fOn Tue, 28 Apr 2015, Richard Biener wrote: 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. > > I am wondering, do we want to keep this "forever", or adjust to > the fact that stage 2 has been non-existent for a while? > > We may not want to redefine stage 3 to 2 and stage 4 to 3, but could > use stage A, B, and C? (Or in fact alpha, beta, and RC phases which > is what this essentially has become?) I think we'd want to transition to more descriptive stage names. Like "Development Stage" (stage1), "Stabilization Stage" (stage3) and "Release Stage" (stage4). Note that Stage 4 is equal to the state release branches are in (but we didn't yet branch for the release), thus "Release Branch Stage" would be even better but also possibly confusing (there isn't a branch). Richard. > > Gerald
Re: missing explanation of Stage 4 in GCC Development Plan document
fOn Tue, 28 Apr 2015, Richard Biener wrote: >>> 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. I am wondering, do we want to keep this "forever", or adjust to the fact that stage 2 has been non-existent for a while? We may not want to redefine stage 3 to 2 and stage 4 to 3, but could use stage A, B, and C? (Or in fact alpha, beta, and RC phases which is what this essentially has become?) Gerald
Re: missing explanation of Stage 4 in GCC Development Plan document
On Tue, Apr 28, 2015 at 7:01 AM, Thomas Preud'homme 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 > >
RE: missing explanation of Stage 4 in GCC Development Plan document
> 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? > > 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
Re: missing explanation of Stage 4 in GCC Development Plan document
On Mon, Apr 27, 2015 at 09:37:36AM +0100, Richard Biener wrote: > On Sun, Apr 26, 2015 at 9:56 AM, Honggyu Kim 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
Re: missing explanation of Stage 4 in GCC Development Plan document
On Sun, Apr 26, 2015 at 9:56 AM, Honggyu Kim 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 > > I have reported a bug recently but didn't clearly understand the term "stage > 4" here. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 > > Do you think "stage 4" explanation is missing in "GCC Development Plan" > document? > If so, can anyone please explain it or write the description on the document? I have committed the following. Richard. 2014-04-27 Richard Biener * develop.html: Document stage 4. Index: develop.html === RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.153 diff -u -r1.153 develop.html --- develop.html22 Apr 2015 11:21:43 - 1.153 +++ develop.html27 Apr 2015 08:36:49 - @@ -127,6 +127,14 @@ require changes to other parts of the compiler. New functionality may not be introduced during this period. +Stage 4 + +During this period, the only (non-documentation) changes that may +be made are changes that fix regressions. Other changes may not be +done during this period. Note that the same constraints apply +to release branches. This period lasts until stage 1 opens for +the next release. + Rationale In order to produce releases on a regular schedule, we must ensure > Thanks, > > Honggyu >
missing explanation of Stage 4 in GCC Development Plan document
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 I have reported a bug recently but didn't clearly understand the term "stage 4" here. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 Do you think "stage 4" explanation is missing in "GCC Development Plan" document? If so, can anyone please explain it or write the description on the document? Thanks, Honggyu
Re: GCC development plan
Piotr Wyderski wrote: Tobias Burnus wrote: Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html Yes, I know those pages pretty well, as I check the C++0x implementation progress every other week. But, from the perspective of trunk, they describe what has already been done and I'm using that features happily. Of course I realize that there is no strict plan, as it is an Open Source project run by volunteers. I would like to know what is in progress or planned /speculated to be, but failed to find that information. The person who maintains the mentioned sites somehow knows what is going on under the hood, so I wonder whether that information is available to mere mortals, and -- if yes -- then how. No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first That would be more than enough, but where can I find that? I read this list rather carefully, however not much information of that kind is disclosed here. Best regards Piotr Wyderski I think there are three broad parts to this question: infrastructure, core language and library runtimes. I tend to work on the latter and in that case I think all the languages are trying to fill any holes in the published standards for those languages. I know at least C, C++, and Fortran have status pages in the manual and in Wikis describing the coverage with respect to the various standards and Technical Reports and Defect Reports in each language. Pick a hole and start filling. As for infrastructure I know much less. It seems that a lot of thought is presented at GCC workshops. Ideas are presented for new optimization passes and so on. Also, watching the list will reveal annoyances like reload and other stuff. Obviously I don't know these parts ;-) well enough to talk. As a core language evolves in subsequent standards (in particular, right now, C++-0x is coming up) new language features must be supported possibly in conjunction with the corresponding runtime. As for timing at least C++ and possibly Fortran track the standards as the progress and add features as they solidify either in an experimental mode or on a separate branch. Gcc is an important part of the feedback loop into the wider standards world about implementation experience for new language and library proposals. So basically, it's this: 1. look at the standards documents, 2. look at the current coverage in gcc, 3. Fill holes, 4. Don't add too much new stuff. Rinse. Repeat. Ed
Re: GCC development plan
Tobias Burnus wrote: > Well, for the new features in the trunk: Have a look at the release > notes for the upcoming version 4.5 at > http://gcc.gnu.org/gcc-4.5/changes.html > For C++ 0x (1x?) have also a look at > http://gcc.gnu.org/gcc-4.5/cxx0x_status.html Yes, I know those pages pretty well, as I check the C++0x implementation progress every other week. But, from the perspective of trunk, they describe what has already been done and I'm using that features happily. Of course I realize that there is no strict plan, as it is an Open Source project run by volunteers. I would like to know what is in progress or planned /speculated to be, but failed to find that information. The person who maintains the mentioned sites somehow knows what is going on under the hood, so I wonder whether that information is available to mere mortals, and -- if yes -- then how. > No - there might be some (tentative) plan for some parts of the compiler > and ideas what should implemented first That would be more than enough, but where can I find that? I read this list rather carefully, however not much information of that kind is disclosed here. Best regards Piotr Wyderski
Re: GCC development plan
On 01/20/2010 12:17 PM, Piotr Wyderski wrote: > is there something like an unofficial documentation > of trunk features Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html > or a more or less detailed development > plan of the compiler? No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first but there is no overall development plan. > What I'm trying to say... how do you know what to work on That depends on who is paying (if any), personal interest, and perceived importance of a given feature/bug. > and what are schedules? See Stage 1/2/3 at http://gcc.gnu.org/develop.html and the time line on that page that gives you an idea of a schedule of GCC (though not for a given feature). Tobias
Re: GCC development plan
On 01/20/2010 12:17 PM, Piotr Wyderski wrote: > Hello, > > is there something like an unofficial documentation > of trunk features or a more or less detailed development > plan of the compiler? http://catb.org/~esr/writings/homesteading/ with the usual caveats about Open Source vs Free Software. Paolo.
GCC development plan
Hello, is there something like an unofficial documentation of trunk features or a more or less detailed development plan of the compiler? What I'm trying to say... how do you know what to work on and what are schedules? I'm particularly interested in C++0x, SIMDs and optimization plans. Best regards Piotr Wyderski
