From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: tests
Date: Sat, 05 May 2007 15:17:52 -0600 [thread overview]
Message-ID: <f1is9u$94s$1@sea.gmane.org> (raw)
In-Reply-To: <200705011508.57220.peper@gentoo.org>
Piotr Jaroszyński wrote:
> Hello,
>
> There was some discussion about forcing/not forcing tests in EAPI-1, but there
> was clearly no compromise. Imho, tests are very important and thus I want to
> discuss them a little more, but in more sensible fashion.
>
> Firstly each test can be(not all categories are mutually exclusive):
> - not existant
> - non-functional
> - not runnable from ebuild
> - useful but unreasonable resource-wise
> - useful and reasonable resource-wise
> - necessary
> - known to partially fail but with a way of skipping failing tests
> - known to partially fail but with no easy way of skipping failing tests
> Is that list comprehensive?
I've been running with FEATURES=test for a long time now. Here's some
of the more interesting cases:
- fail only on little/big-endian archs
- fail only with/without root privs
- fail only if dependencies are / are not compiled with certain optional
support
- fail only with GCC >=4
- are expected to fail and are only meant as a regression test
- take 3 minutes on x86 and 3 hours on mips
- fail on hardened
- fail with/without new tar versions
- fail with/without new flex versions (etc.)
- fail if a kernel component is a module instead of built-in
- fail if certain environment variables are set
- fail if compiled with certain (safe) CFLAGS/CXXFLAGS
Can we qualify each of these into one of your categories? (NB: I
realize there are solutions for each of these examples. I'm pointing
out that not only is the situation not black and white, it often ranges
in the ultra-violet.)
> Secondly we must answer the question how precisely we want to distinguish
> them, so users/dev can choose which categories of tests they want to run.
> What comes to mind is:
> - run all tests
> - run only necessary tests
> - run only reasonable tests
> - don't run tests at all
> Again, is that list comprehensive?
- run only tests that don't require extra deps
- run only tests that work on hardened
- run only tests that work on my arch
> Please don't post solutions unless we figure out which options we really want
> to deliver.
Sorry. (neener neener) ;) Would people accept running src_test() by
default only on packages in the system set? There are some that we
might want to turn off - glibc, gcc, binutils, autoconf, and automake
are on my current short list. coreutils is also a lot of fun. db takes
six hours.
Anyone, however, who is of the opinion that tests for their packages are
so important that they should never be skipped, and who is willing to
deal with the bug reports that will undeniably be generated as a result,
should IMO be allowed to shoot themselves in the foot, while those
uninterested can go about their business without further interruption.
In no way should this be tied to EAPI.
--
where to now? if i had to guess
dirtyepic gentoo org i'm afraid to say antarctica's next
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-05-05 21:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 13:08 [gentoo-dev] tests Piotr Jaroszyński
2007-05-01 13:24 ` Josh Sled
2007-05-01 13:32 ` Ciaran McCreesh
2007-05-01 15:50 ` Alec Warner
2007-05-01 16:04 ` Daniel Gryniewicz
2007-05-01 16:23 ` Vlastimil Babka
2007-05-01 17:18 ` Maurice van der Pot
2007-05-01 17:35 ` Ciaran McCreesh
2007-05-01 19:53 ` Maurice van der Pot
2007-05-01 20:05 ` Piotr Jaroszyński
2007-05-02 5:58 ` Rémi Cardona
2007-05-02 6:53 ` Danny van Dyk
2007-05-01 21:52 ` Josh Saddler
2007-05-01 22:31 ` Stephen Bennett
2007-05-01 22:28 ` Josh Saddler
2007-05-01 22:47 ` Piotr Jaroszyński
2007-05-01 23:08 ` Ciaran McCreesh
2007-05-01 23:06 ` Ciaran McCreesh
2007-05-01 17:58 ` Piotr Jaroszyński
2007-05-01 19:24 ` Rémi Cardona
2007-05-01 20:10 ` Jure Varlec
2007-05-01 22:06 ` Robin H. Johnson
2007-05-01 20:25 ` [gentoo-dev] tests Piotr Jaroszyński
2007-05-01 23:32 ` [gentoo-dev] tests Marius Mauch
2007-05-01 23:46 ` Daniel Gryniewicz
2007-05-01 23:55 ` Ciaran McCreesh
2007-05-02 0:34 ` Brian Harring
2007-05-02 11:52 ` Ciaran McCreesh
2007-05-02 0:08 ` Robin H. Johnson
2007-05-02 0:12 ` Stephen Bennett
2007-05-02 1:51 ` Daniel Gryniewicz
2007-05-02 6:49 ` Danny van Dyk
2007-05-02 11:56 ` Ciaran McCreesh
2007-05-01 23:56 ` Ciaran McCreesh
2007-05-02 10:54 ` Philipp Riegger
2007-05-02 20:05 ` Mike Frysinger
2007-05-02 20:12 ` Ciaran McCreesh
2007-05-06 8:39 ` Mike Frysinger
2007-05-05 21:17 ` Ryan Hill [this message]
2007-05-06 4:27 ` [gentoo-dev] tests Alistair John Bush
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f1is9u$94s$1@sea.gmane.org' \
--to=dirtyepic@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox