This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Status (2004-08-09)
Geoffrey Keating wrote:
> 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.
This makes a lot of sense. Thanks for bringing this up.
> 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.
I do not agree here. A complex bug could be totally unimportant at some point
for the handful of persons that can actually fix it, because of their personal
schedule, job, whatever. But if the bug is a serious regression, shipping GCC
cannot be an option. Shipping versions with too many regressions is a good way
to avoid people upgrading their compilers. Many people are upgrading from 2.95
only now, and I think it is also thanks to the high quality releases we are
getting these days.
> 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.
You can filter bugs based on the severity in Bugzilla. If you care only about
showstoppers, just filter out anything which is not a regression and it is not
marked as "critical". There are also minor regressions targeted at the next
release, because people do not expect things to break when they upgrade. But of
course, if your time is limited you can just concentrate on the serious
regressions.
After all, this is what the release managers do: many non-serious regressions
are often delayed from release to release.
Giovanni Bajo