GCC 4.3 release schedule

[Andrew MacLeod]

Richard Guenther wrote:
> 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 ;)
>
>   
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