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