Re: GCC 3.1 Release

[Andreas Jaeger <aj@suse.de>]

Geoff Keating <geoffk@geoffk.org> writes:

>> 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.

This is not possible for people that are behind a firewall...

Would the main tester run a script on the slave and connect to it via
ssh?  Or would it be possible to work the other way round: The slave
asking the master whether there's work to do?

> 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.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj