"ways of accomplishing ... the basic goal"

[Lars Segerlund]

  The only 'cross build -cross platform' application compilation 
framework I am aware of is the debian build system, I don't know if it's 
adaptable to the desired setup, but otherwise  ( given the resources ), 
it should be possible to setup a complete debian build of stable, 
installation from it and running of a major test sequence all automated.

  If possible runtime errors are ignored, the build of all this software 
( 12000 ) packages should be possible, since it is already in place, ( 
the framework ).

  For selected applications this would be even easier since the apt-get 
tool can do a download/build/install from source, and thus single 
applikations could be tested.

  I don't know if this is of any help, I'm just shooting of to show, 
that such a build wouldn't be that hard to do, and there are certainly 
other similar systems.

  / Lars Segerlund

Joseph S. Myers wrote:
> On Thu, 6 Feb 2003, Tom Lord wrote:
> 
> 
>>   It appears that, for large changes, it is de rigeur to merge into
>>   the mainline first, then fix some of the new regressions second.
> 
> 
> Do you have any actual example of this, where a branch merge wasn't tested
> with no regressions in the testsuite on three platforms as required?
> 
> The problem after merges is mainly _unknown_ regressions - regressions not
> shown up in the testsuite.  Many of these could perhaps be found by bulk
> builds of real world software - such as BSD packages/ports collections and
> GNU/Linux distributions - but doing such builds requires vastly more
> resources than a bootstrap/test of GCC.  
> (<http://gcc.gnu.org/ml/gcc/2002-10/msg00503.html> reports that a bulk
> build of FreeBSD packages takes 24 hours on a cluster of 8 Pentium-III/800
> machines.  For effective reduction of regressions in GCC this way you'd
> need at least such a cluster dedicated to testing GCC daily - for mainline
> and each branch tested.  Preferably more often than daily, to identify
> individual patches responsible, though to some extent - if some machines
> are e.g. dedicated to providing hourly copies of GCC for binary search -
> binary search could be used for each broken package to find which patch
> broke it, without building everything every hour.  And then you want some
> human filtering for the cases where the problem was in the code that
> broke, not in GCC.)
>