Richard Guenther wrote:
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> 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 ;)
we can at least make projected dates known so we have something firmer
than "at some point in the future" :-)
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).
I got the impression from marks latest note that he was planing to cut a
4.3 branch when we got down to 100 P1s.
We're still in Stage 3 for GCC 4.3. As before, I think a reasonable
target for creating the release branch is less than 100 open
regressions.
This was where I was going with the nov 14th date as a latest target.
So you are saying we shouldn't branch at this point?
I'd like to see some stabilization... Ie, not hunks of new functionality.
Early Q1 for 4.3.0 works for us for a release. I had no idea any one
else cared when 4.3 goes out.
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 ;)).
It would be excellent to have both openSUSE and fedora pounding on 4.3
at the same time.
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.
having a RC by the beginning of february seems reasonable to me :-) mid
january would be even better.
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).
I understand, but without some sort of date guideline, you cant plan on
using as yet unreleased compiler. It buggers up the release cycle. I
don't propose the date as a hard release criteria, but as a target that
we'd like to work towards. So what I'd like to see is what the final
release requirements are, and then along they way we can monitor the
current status and if we are falling behind, can try to apply more
resource to it to get back on track.
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.
Right. so I'm not looking to lock into Feb 29th as a rock hard release
date, but I would like to see the project agree that it would be good to
target releasing on a specific date and work towards that with dated
milestones. if we are ready earlier, awesome, if we're later, shit does
happen, but it would be good to have a date in mind people can focus on.
Its easier for other projects to work with you if you at least have a
schedule date they can use.
As you say, enough engineering resource is likely to make it happen, but
projected dates give external groups warmer fuzzies and makes it easier
to allocate engineering resource.
So lets see, the dates you gave were targetting RC1 for gcc4.3.0 say
Feb4 (giving us the weekend :-) and the full release say 2 weeks later,
Feb 18th. (as target dates :-) Anyone think we can pull these dates in
at all?
do we actually have criteria for what is required to reach RC1? I would
like to see something.
Andrew
