Re: V3: SPARC bug and tree freeze

[dewar at gnat dot com (Robert Dewar)]

<<Is the technology you use for this available for public use?  I'd
certainly love to have something like this for some projects I happen
to be a maintainer of.  And I don't think it would be a bad idea to
have to in GCC either, even though we might need a very fast machine
to keep up with the volume of patches.
>>

Potentially yes, it is a bunch of scripts that would need quite a bit
of massaging for general use. This might be something that Laurent
Guerby could help with. What we do at ACT is to have about ten machines
with various architectures available to run the tests. Most patches
are tested on just one machine (submitters choice), but occasionally
where you know there are target dependent issues, you can run on several
machines simultaneously. Then every night, we run on all machines to
make sure that

a) there is no case of two patches conflicting (very rare)

b) there is no case of a patch causing some kind of target dependent
regression (not so rare, happens perhaps one out of ten nights).

"a very fast machine"

First, you can get a fully configured gigaherz machine these days for
under $2000 that can chew things pretty fast.

Second, the "a" here can definitely be changed to "several". 

I do not want to minimize the effort in setting up something like this.
The scripts involved are complex, and it is hard work to maintain the
test suite in a form suitable for the automatic scripts, but we have
found this approach invaluable in avoiding regresssions. 

Robert