This is the mail archive of the 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

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 :-)


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