On Thu, Oct 09, 2003 at 02:15:03PM +0200, Bill Allombert wrote:
> My first goal is to persuade developers that running tests is
> worthwhile. For the implentation I have mainly 3 questions:
>
> 1) Do porters and autobuilders admins want to be able to skip the tests ?
As a porter: No. Dear god, no. I regularly submit bugs asking folks to
turn ON the testing already present in the package, so that we can catch
problems with it more readily.
As an admin of a box that isn't a buildd, but looks much like one: it
spends far more time dealing with build environment setup/teardown, most of
the time, than it ever does running tests. Most testsuites are small, fast,
and add maybe a tenth again, if that, to the build time (GCC is probably
the most notable exception, but I still make sure it always runs it's
checks when doing a formal build - it's worth it).
> 2) Do we need a more featureful test machinery that just running test
> in the debian/rules build ?
Having a 'test' target would be handy, if for no other reason than being
clear on exactly where and when testing should take place (and, really,
being able to NOT test if one is, for some reason, averse to it - say,
doing multiple rebuilds that aren't intended for packaging/release.
> 3) Do we want to allow for autorecovery ? If gcc -O2 leads to a broken
> binary, why not set up debian/rules to automatically retry with gcc
> -O0 ?
On this, I have to vote 'no'. If switching from -O2 to -O0 fixes a problem,
that is almost indisputable a bug (usually in the toolchain), and there
should be human intervention if for no other reason than ensuring the
toolchain packages get the bug filed against them so that we can improve
them.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpLOIkIhQnBa.pgp
Description: PGP signature