running all the tests
Werner Koch
wk at gnupg.org
Mon Aug 7 17:23:54 CEST 2017
On Mon, 7 Aug 2017 14:36, dkg at fifthhorseman.net said:
> But I'm a little worried about this resolution, because it means we'll
> be less likely to get alerts about failure in many places (including the
> debian build daemon network, which tests over a dozen platforms but does
The extra tests we don't let the user run are combinations of
non-default options. In particular keyring/keybox things. However, we
run them on our Jenkins and by testing them on 32 and 64 bit Unices, 32
bit Windows, and macOS it is very likely that we catch such rare errors
and are able to fix them before we do a release. It does not help the
user to detect a programming error. The user initiated "make check" is
to assure that the build was correct.
Note that for Libgcrypt we are even not running some tests on Jenkins
but only run them by hand before a major release. They take several
hours.
I expect that we will get even more tests in GnuPG and thus we need to
decide which tests can be run how often and what the benefits of these
tests are.
There is a way to run the checks in parallel but that is not the default
because we like to have comparable test runs and don't depend on the
order of execution. And they help only on multi-core CPUs.
Maybe we should enable parallel tests in --enable-maintainer-mode by
default, though.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170807/a8b55ab2/attachment.sig>
More information about the Gnupg-devel
mailing list