xfs
[Top] [All Lists]

Re: xfstest failures

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: xfstest failures
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 07 Nov 2013 07:46:43 -0600
Cc: Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131107132739.GA16608@xxxxxxxxxxxxx>
References: <20131106105451.GA31283@xxxxxxxxxxxxx> <20131106161825.GU1935@xxxxxxx> <527A887F.2030807@xxxxxxxxxxx> <20131107081710.GC25157@xxxxxxxxxxxxx> <527B948C.9060905@xxxxxxxxxxx> <20131107132739.GA16608@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
On 11/7/13, 7:27 AM, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:24:28AM -0600, Eric Sandeen wrote:
>> On 11/7/13, 2:17 AM, Christoph Hellwig wrote:
>>> On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
>>>> that's right, it's a known bug w/ a testcase but no fix yet.
>>>>
>>>> I looked a bit, but ugh, xfsdump.
>>>
>>> Maybe it's time you come up with an xfail mechanism at least?
>>
>> What's the proposal there, a "fail" group for things known to still
>> fail everywhere?
>>
>> so i.e. ./check -x fail ?  I can easily send a patch for that if
>> that's what folks want.
> 
> A mechnism to annotate a test as xfail, so that check would output them
> at the end ala:
> 
> Expected failures:  common/263
> Unexpected successes: reiser4/001
> 

The thing that's tricky about that is that what's expected depends
so heavily on what kernel is running.

Would an expected failure be only for tests which are known to be
not-fixed anywhere?

-Eric

<Prev in Thread] Current Thread [Next in Thread>