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.
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.
Andrew
