Re: GCC 3.3, GCC 3.4

[Mark Mitchell <mark at codesourcery dot com>]

--On Friday, January 31, 2003 11:03:41 AM +0000 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
>
> > I think the longer gcc, as a project, goes on without an autobuild
> > continuous regression checker, the worse off things will get.
I've caught up now on this entire thread, and I spent about an hour
talking to Benjamin last night.  I appreciate the time he took to
talk to me and the input he provided, including some practical notes
about when Red Hat people would be more likely to help and when they
wouldn't.

If people have concerns about how I'm doing my job, I want to hear
them.

My job as RM is to serve the FSF's interests -- not CodeSourcery's,
or anyone elses.  It's a little unclear what the FSF's interests *are*,
other than the overall success of free software, but I've got to assume
that they include the widespread usage of GCC and the avoidance of forks,
which, to me, implies reasonably high-quality releases reasonably often.

I find it a very hard balancing act.  Do releases often, and you're
always working on fixing regressions, testing, packaging, etc.  Do
releases rarely and the bugs get so bad it's incredibly hard to fix
them all.  Do them on a major GNU/Linux vendor's release schedule and
you get more help from those vendors, but maybe not at a time that's
terribly natural for the pace of other development.  Decide that
there have been enough major changes for one release, and you risk
irritating the people who have been working on the branch that didn't
get in.  Take the code anyhow and you risk introducing more bugs and
exposing users to immature technology.  You get the picture. :-)

I completely agree that more automated testing, and non-automated
testing, would be extremely helpful.  I also agree that more bug-fixing
would be good; right now we *know* about a lot of regressions -- but
we don't have fixes for most of them.  Architecture cleanups that make
it harder to introduce bugs also help a lot.

Nobody seems to be objecting particularly much to the idea of leaving
stage 1 for GCC 3.4 on March 15th.  So, let's make that firm.  We've
already got two major pieces of new technology: a new C++ parser, and
PCH support.  There are still serious bugs in both, no doubt, but we're
making good progress.  I think if we get another branch merged in,
we'll have enough bugs to keep us busy forever.

As for GCC 3.3, I guess we'd better play it a bit by ear.  It doesn't
appear that most people think we can make March 1.  I'm going to keep
that as my own internal target, so that I have something to motivate
me to fix a bug or two on a Saturday night, but we'll not be too firm
about it.

Thanks to all of you for commenting.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com