On Tue, 2005-06-14 at 09:01 -0700, Mark Mitchell wrote: > CodeSourcery struggles with exactly the same problem; we have worked > hard to set up some test automation for our ARM builds, and it's working > well, but we're not (yet!) as disciplined as we want to be about > analyzing and fixing the failures.
At AdaCore (I assume it's still the rule), a patch was allowed to be committed only *after* a special run of the regression tester with CVS source baseline + only your patch showed a clean run (it was all automated so you just had to provide a clean patch to the system). That cleans-up the area of who has to do the analysis, and it's on a patch the person just wrote so no precious brain time wasted in refocus and analysis of random failures. If the patch is judged correct but triggering a latent bug somewhere else, the person that will work on it will also start from a small set of triggering conditions so an easier task overall. This leaves: - the problem of interaction of two patches committed the exact same day that have a bad interaction, but this is quite rare even for GCC. - if you don't have enough ressources to run simulators, platform specific problems. The only missing piece for such a setup to be workable for GCC in the FSF framework is some dedicated computing ressources, plus someone to do the script work. Laurent
