This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.1 Release
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