Re: GCC 3.1 Release

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> The amount of breakage since GCC 3.0 continues to amaze me.

Me too.

Mark> It's really unfortunate that there have been, again, over a
Mark> hundred *regresssions from GCC 3.0* during GCC 3.1 development.

For gcj the main developers seem to all use Linux; x86 and PPC seem to
be the most popular.  During the 3.1 process we've gotten a lot of bug
reports about platforms that aren't ordinarily tested.  In none of
these cases did we consciously break gcj on a given platform.

What I'd like to see in the future is for people to set up automated
regression testers, say like Geoff's, that test these platforms.  Then
we simply won't introduce problems in the first place.

In fact what I'd really like to see is a requirement for such a
regression tester for every platform that is considered release
critical.  (I'm sure the logistics of this are difficult.)

For gcj at least it would also help if we greatly expanded the test
suite.  Even simply requiring a Mauve run before a commit (or after,
in the regression tester) would have helped us a great deal.  Now,
Mauve is automated in our test suite, but other useful things like
Classpath, rhug, kawa, etc, are not.  So this is something we can do
pretty easily that will help reliability.  Still, the big thing is
getting this automated so that regressions are short-lived.

Another thing that has happened is that the impending release brought
all kinds of new gcj ports out of the woodwork.  It would be nice if
these weren't all batched at one point in the process.  I'm not sure
what, if anything, we can do about this.  Perhaps this phenomenon is
unique to this release.

I'd say most of the time I've spent on 3.1 (and it is a fair amount of
time, at least 2 full weeks) has been spent handling ports which
worked in 3.0 and stopped working somewhere along the line.  It isn't
exactly fun work, and it has even perhaps blocked me from fixing a
non-port-related gcj bug.  This sort of thing is preventable, so let's
prevent it.

Tom