Re: GCC 4.3 release schedule

[Andrew MacLeod <amacleod at redhat dot com>]

Mark Mitchell wrote:
> Andrew MacLeod wrote:
>
>   
> > we can at least make projected dates known so we have something firmer
> > than "at some point in the future" :-)
> >     
>
> As RM, I try to take into account what I know about when distributors
> will be applying effort, but I must absolutely avoid in any way tilting
> the FSF release process towards the needs of one distributor, possibly
> at the expense of another.  I don't think it's appropriate for us to set
> a schedule tailored to any one distributor's needs -- and there are a
> lot more distributors than just Red Hat and SuSE, so I'd say that even
> if you were on the same schedule.  But, I certainly do think it's
> helpful for a contributor to tell us when resources might be available
> and I appreciate you sharing that information.
>
>   

I'm not suggesting we tailor the schedule to a specific distributor, but 
I do think when we have useful information that a client of GCC will be 
choosing a release by $date, it might be worth considering how that fits 
into the current or future release schedules.  Fortunately we seem to 
have an alignment of the planets at the moment, so it doesn't appear it 
will be much of an issue for this release. we got lucky. 12 months ago, 
it might have actually been planned instead of luck  had fedora and suse 
said our plans are to be looking for a compiler in early Q3/2007 and 
then again in Q1/2008. And if other distributions provided approximate 
dates, we'd see where "ooo, look, 5 distributions will be looking for a 
compiler in Q1/2008.  perhaps we should try to arrange our schedule to 
have a release available then.  That means stage 1 goes to june, stage 2 
goes to mid september, and that should result in a release in late 
Q4/early Q1 which all those distributions will be interested in".  I 
think we'd see a lot of resource pumped into getting that release out.   
If the schedule had shown not more than 1 distribution was looking for a 
release until June of next year, perhaps we decide to delay things 
further to allow more development.

One of the reasons we sometimes languish in stage 3 is because a release 
is not interesting to enough parties. They end up spending their 
resource working on a future release which will be of interest to them, 
and stage 3 drags on.   I think our best bet at making stage 3 practical 
and short is to have enough interest in getting the release out.   And 
the reality of the situation is that you probably need a couple of 
distributions interested in it. It looks like thats the case with this 
release, and I am hopeful that we are going to have a reasonable stage 3 
and get a release out in a timely fashion. In the future, we can 
probably accomplish the same thing if we try to align a release date 
with interested parties.


> If you're interested in driving the release to a particular date, the
> best thing you can do is to go clear out the P1s in bugzilla and then
> bash out a few P2s.  (I've noticed Red Hat folks doing some of that
> already, thanks!)  I'd imagine that the dates you want to hit would be
> achievable if you, Jakub, Jason, etc. all work on issues.
>
>   
We do intend to do that, but its easier to get the resource assignments 
if we can say "gcc 4.3 is currently planned to be released on Feb 8th, 
but we need 25% of 3 developers for 3 months to help make sure".  It 
boils down to the same thing to you and me, but not to the other 
projects and people involved.  If we can set a trend like this, and we 
meet a couple of release dates accurately, we might be able to regularly 
get resource assigned to releases.


> I've found schedules for GCC to be very hard to predict.  As I said in
> my status report, our practice has been to cut the release branch when
> we reach 100 regressions, and release 2-4 months after that point,
> depending on quality on the branch.  To be honest, I'd rather wait
> longer to make the branch -- but there tends to be intense pressure in
> the developer community to make a branch so we can get on to the next
> round of major features.  In any case, after we make the branch, it's in
> regression-only mode, so stability tends to be quite good, though
> dot-zero releases are, after all, dot-zero releases.
>   

Yeah, I'm not so concerned about whether we cut a release branch early 
or not. Cutting a branch, or saying mainline is regression only, or 
whatever mechanism boils down to the same thing. The key is to get 
people working on it because the release is needed.   If the release is 
needed, its likely to be needed by a certain date. In the past our dates 
have been set fairly arbitrarily by ourselves right?  If our date 
coincides with dates that others actually need the compiler by, I bet we 
see a lot less slippage.  I just suggest we try it, it really not that 
big a change in my view, and I think it may solve come of our problem in 
getting focus on releases.  I have no doubt that if we set a date in 
early february, we'll probably make it.  And I'd like to see if we can 
reproduce that in the future.

Just my opinion :-)

Andrew