This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.3 release schedule
Andrew MacLeod wrote:
> we can at least make projected dates known so we have something firmer
> than "at some point in the future" :-)
The canonical rule of project management is: "Features, Schedule, Cost:
Pick At Most 2." :-) In other words, you can decide what features you
want and when you want them by -- but be prepared to pay for a vast
team. Or, you can decide what you want to pay, and when you want it --
but be prepared to get whatever features are done by then with the team
you paid for. In the case of GCC, it's worse than that since we're not
all interested in the same things, or being in any way centrally directed.
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.
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.
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.
(650) 331-3385 x713