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] | |
Sure, I think it boils down to the same thing from a conceptual point of
view, but perhaps the nitty gritty details are easier if you keep it as
mainline so we dont have to check everything into 2 branches. Bottom
line is you freeze development until its time to release.
Well... this is the point of having stage3 ;) Of course work goes on on
branches. One point of essentially freezing mainline until the release
is to not pessimize people fixing bugs for the release instead of doing
work on the already-open-after-branching stage1. This theoretically
I don't think we need a 6 month release cycle myself, but maybe thats just me. Are people actually looking for new compilers that frequently? I wouldn't think that would be the norm. thats barely time for the compiler to properly stabilize. I think it would be even harder to get focus on stage 3 that frequently. I still think we need to try to have a look at the schedules of the various groups that USE the compiler, and set our release schedules to something that is going to be useful to multiple groups, thus generating the most interest in a release.would allow shortening stage1 drastically (to lets say 2 weeks of branch merging and another 4 weeks of general "patches") to get back to a 6 month release cycle (I personally think the each-stage-is-2-month is not realistic).
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |