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
