Re: GCC 3.1 Release

[Geoff Keating <geoffk@geoffk.org>]

> Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
> From: Jason Merrill <jason@redhat.com>
> Date: Sun, 14 Apr 2002 14:05:55 +0100
> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
> 
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> 
> > 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.)
> 
> Absolutely.  Geoff, how hard would it be for someone on the net to set up a
> slave tester to improve coverage?  I'd like to keep the bookkeeping
> centralized, but the actual testing work can and should be distributed.

Once sufficiently fast hardware is available, setting up a slave
tester should be very easy.  I think it should go like this:

1. Set up a tester with some reasonably reproducible software
   configuration (so that others can reproduce bugs).  For example,
   the current tester is configured as "Red Hat Linux 7 from CD plus
   all updates so far".

2. Make GCC mainline bootstrap on this machine, preferably using the
   scripts in gcc/contrib/regression.  Check that the bootstrap & test
   takes less than about 3 hours.  [For reference, a single 800Mhz
   Pentium III can do this.  A two-processor 450Mhz machine should
   also be able to do it.  Old obsolete hardware from the early 90s
   certainly can't do it; if it turns out that all we can get is old
   obsolete hardware, I'll have to change the tester so that it
   doesn't have to wait for all the builds to finish, but this will
   take some time.]

3. Set up an account so that the regression tester can log in,
   preferably using SSH.

4. Then I'll check that everything works and add the new target to the
   tester.

Typically, I find step 2 to be the tricky bit for new targets---often,
the new target doesn't build.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>