Re: GCC Status (2004-08-09)

[Geoffrey Keating <geoffk at geoffk dot org>]

mitchell@mail.codesourcery.com writes:

> In terms of time frame, I'd like to go to Stage 3 on or about
> September 5th.  If there are additional LNO changes that have a
> positive impact on performance, we can consider them after that time.
> The final GCC 3.5 release date will depend largely on the rate of bug
> fixing, but early 2005 seems likely at this point.

I would suggest that if we're going to go into stage 3, but still
allow patches for compile speed, code quality, and bug fixing, we
might as well call it stage 2.

I would also strongly suggest that we not go into stage 3 before we've
decided on *achievable* release criteria.  I would not like to see a
situation where we go into stage 3 because we've passed an arbitrary
deadline, and then stay there for many months because of unachievable
targets for branching.  If we're going to go into stage 3 because of a
date, we should equally make a branch and a release based on a date;
if we want to branch/release based on quality goals, then stage 3
should also have a quality goal.

I don't think that making a release based on a deadline would be a bad
thing.  If people consider that some outstanding bugs are important,
then giving a date by which they must be fixed to go in the release
will help them prioritize their time.  If no-one considers the
remaining bugs to be worth their time, then we shouldn't hold the
release for them.  We can always delay the release if (enough)
individuals say "I want to work on this bug but can't get to it until
two weeks past the deadline."  It might help to actually ask people
who have bugs assigned to them whether they think that the deadline is
reasonable; I find it concentrates minds a lot to say "you have 27
bugs assigned to you targetted at the next release, do you really
think you can fix them all in two months?"

I also have a suggestion about release targets for bugs.  At the
moment, we target bugs at the next release that we think it could
possibly be fixed in.  This leads us to having hundreds of bugs
targetted an the next release, many of which are not important and
which no-one is working on.

Instead, I think we should by default target bugs at no particular
future release, and only target bugs at the next release if we really
expect them to be fixed in that release, because either someone is
working on them now, will work on them before the release, or because
they're so important that someone has to be found to work on
them---and the last category should be small, and highly visible,
small enough that we can do things like call for volunteers on
gcc-announce ("We are going to deprecate target XXX unless someone can
be found to fix this bug").  That would make it much easier to see the
status of a release and which bugs are really blocking it.