This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: Bernd Schmidt <bernds at redhat dot com>, "dewar at gnat dot com" <dewar at gnat dot com>
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 10 Jul 2001 17:40:07 -0800
- cc: "aoliva at redhat dot com" <aoliva at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "kenner at vlsi1 dot ultra dot nyu dot edu" <kenner at vlsi1 dot ultra dot nyu dot edu>
> I'd prefer to delay such an action until a release is imminent, on the
> grounds that a failing test is a useful piece of information we shouldn't
> lose (of course this requires that we keep track of why it's failing).
If a release is imminent, and we have known testsuite failures, we are in
trouble. That means we have to try to fix those bugs, and all the other
bugs we will inevitably find when testing for the release. This is part
of how we get to having such a long release cycle.
We have to remember that we are not a normal development organization.
There is *no mechanism* for making anyone fix changes, ever. We
cannot simultaneously meet the goal of (even semi-) regular releases,
and high quality releases, without making someone responsible for
fixing newly introduced bugs.
In any case, I came to a very basic conclusion during the 3.0
release cycle. If we allow buggy checkins (again note earlier
compromise regarding "latent" bugs), then the job of Release
Manager is not a management position at all. It is the job
of Cat Herder. And there are a lot of cats.
We need to compromise between the bazaar and the bizarre, here,
folks.