On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > >> 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 > > > > but people do continue working on branches parallel to stage 3, and we > are looking for a way to focus people onto stage 3 in order to get it > out in a timely fashion. simply locking it down doesn't do that, either > in a branch or on mainline, we've seen it in the past. I've been guilty > of it. I have had other big ticket items I'm working on, and if the > release isn't something that fits into plans anywhere, it doesn't matter > when it gets released, so the other work is more important. And lets > face it, bug fixing isn't exciting and motivating work to most people. > We need a reason to get interested enough to focus on getting the > release out.
That's true. We need to ensure we end stage3 with a release (even if it will be of worse quality than usual, just because nobody was really interested in it). Just opening stage1 and _not_ releasing doesn't make this particular situation better. > > 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). > > > > > 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. *sigh* - also true. I thought with a shorter release cycle it would be easier to tell people "no, your feature is not ready for this stage1, just wait N month until next stage1" with N being reasonable (that is, less than half a year). For 4.3 we had a nearly 8 month stage1(!) and doing release planning in advance (the scheduled project list) before any code exists doesn't help this. We simply shouldn't promise to merge anything for a specific release. We should merge things when they are ready and when trunk is in the right stage. But I guess the GCC development model just doesn't work like this :( Richard.
