This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fixing Bugs (Was: A Suggestion for Release Testing)
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