This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [2.20] [6/6] Do not terminate default test runs on test failure
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Brooks Moses <bmoses at google dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 12 Feb 2014 15:48:07 +0000
- Subject: Re: [2.20] [6/6] Do not terminate default test runs on test failure
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401100208000 dot 9412 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1401100214150 dot 9412 at digraph dot polyomino dot org dot uk> <52F96A80 dot 4070806 at google dot com> <Pine dot LNX dot 4 dot 64 dot 1402110014470 dot 26591 at digraph dot polyomino dot org dot uk> <CAOxa4KqYaxsvbyOzK=SftTQQ8j=EEo90O67KtNqhV-N3h5SNxg at mail dot gmail dot com>
On Mon, 10 Feb 2014, Brooks Moses wrote:
> True, and I strongly agree with the sentiment! However, often the
> failures get sorted out in trunk (or in the Linux kernel), and we are
> working on an older release branch, and even if fixes get backported
> the right answer is often to xfail locally while discussing upstream.
>
> For what it's worth, here are some discussion threads related to tests
> we've disabled locally:
> http://cygwin.com/ml/libc-alpha/2010-09/msg00030.html
> http://cygwin.com/ml/libc-alpha/2012-02/msg00466.html
> https://sourceware.org/ml/libc-alpha/2012-10/msg00021.html
>
> Beyond those, we also disabled nptl/tst-robust8 because of flakiness
> (I don't know details there), and rt/tst-cpuclock1 and
> rt/tst-cputimer{1,3} because of virtual-machine issues in the test
> environment, and I think that's all.
Well, if any of these aren't resolved in current glibc, the usual
principle applies of keeping pinging and working on driving things to
consensus until the issue is resolved. And if a fix depends on a new
kernel feature it may be appropriate to make the tests laxer when run on
older kernels - as long as there are appropriate __ASSUME_* conditionals
on the laxity so that it's clear when it can be removed because the older
kernels are no longer supported.
--
Joseph S. Myers
joseph@codesourcery.com