This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.3 release schedule
On 10/29/07, Andrew MacLeod <firstname.lastname@example.org> 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 :(