Re: GCC 4.3 release schedule

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>
> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
> would be nice to keep this stage short and get a release out.
>
> We are interested in using 4.3 as the system compiler in Fedora 9, and
> as such, we'd like to nail down some time lines and requirements with
> release management and the steering committee.

Of course it doesn't work like this ;)

> The timelines involved are something like this:  (clearly anything
> earlier would be great :-)
>
> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally
> we'd have a branch cut no later than that and starting to stabilize
> without much new code going in.

I oppose to cut a branch without immediately releasing 4.3.0.  This just
doesn't work - just look at the history.  I also think that Nov 14th is _very_
optimistic (I personally was thinking about a (early) Q1 release).

Note that we are building what-becomes-openSUSE 11.0 with current trunk
in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
(unless I get pushed back again ;)).

> Dec 14th - viability decision on using 4.3 as the F9 compiler.  There is
> a window here as late as Jan 14th, but the opinions will start forming
> in Dec. There shouldn't be any ABI changes from this point on.
> Feb 29th - Optimistic target date for a 4.3 release.  can slip as much
> as a  month,  but clearly the earlier the release happens the better.

If we branch too early I bet we will not make even the Feb 29th date.

How does targeting a release around Feb 1st sound (that is, without
branching before, a RC1 on Feb 1st, the release including branching
a week or two later)?  It looks like that would work for your constraints.

> I don't recall seeing any other timeline requirements, does this seem
> like a reasonable target schedule? Once a decision is made to use 4.3 by
> mid-jan, it becomes very difficult to back out if something happens to
> the release date, so it becomes quite important that the final criteria
> is well understood by then and appears reachable.  If something
> unforeseen happens late in the cycle to delay the release, its also
> important that we can get some sort of steering committee agreement on
> what to do so we don't have some sort of evil gcc offspring as happened
> once before.

Once again - GCC development and release planning doesn't work this way.
But instead you (and me and others) are supposed to make the release "happen"
by fixing bugs and fulfilling the release criteria.  A "date" wasn't a
release criteria
in the past and I don't think it should become one (in fact, the only
time a release
"date" would be a welcome criteria is if the release is a throw-away
and releasing
would allow us to work on next stage1 again).

> Thats something I don't expect to happen, but will have to
> visit as risk management before the final decision is made.   My hope is
> that it'll be in good enough shape by mid january that slippage by that
> much is unlikely and isn't an issue.
>
> Does this seem like a reasonable schedule?  Can we set the criteria for
> what a final release would look like?  We're committed to applying
> engineering resource to help make it happen.

Again, if you commit enough engineering resource to make it happen, then I'm
sure we'll make your timeline.  If not, well - shit happens?.  At
least I wouldn't
like to see us to be locked in into some agreement around release dates.  After
all this doesn't work for glibc (ok, _that_ probably works for RedHat)
or the kernel
either.

Just my $1000M dollars.

Again - please don't branch without releasing.
(repeat 1000 times).

Thanks,
Richard.