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]

Re: GCC 4.3 release schedule


On 10/29/07, Andrew MacLeod <amacleod@redhat.com> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]