Re: [PATCH v5 1/5] iotests: remove 'linux' from default supported platforms

[Max Reitz]

On 28.09.19 01:35, John Snow wrote:
> 
> 
> On 9/23/19 9:09 AM, Max Reitz wrote:
>> On 18.09.19 01:45, John Snow wrote:
>>> verify_platform will check an explicit whitelist and blacklist instead.
>>> The default will now be assumed to be allowed to run anywhere.
>>>
>>> For tests that do not specify their platforms explicitly, this has the 
>>> effect of
>>> enabling these tests on non-linux platforms. For tests that always specified
>>> linux explicitly, there is no change.
>>>
>>> For Python tests on FreeBSD at least; only seven python tests fail:
>>> 045 147 149 169 194 199 211
>>>
>>> 045 and 149 appear to be misconfigurations,
>>> 147 and 194 are the AF_UNIX path too long error,
>>> 169 and 199 are bitmap migration bugs, and
>>> 211 is a bug that shows up on Linux platforms, too.
>>>
>>> This is at least good evidence that these tests are not Linux-only. If
>>> they aren't suitable for other platforms, they should be disabled on a
>>> per-platform basis as appropriate.
>>>
>>> Therefore, let's switch these on and deal with the failures.
>>
>> What exactly do you mean by “deal with the failures”?  Do you have a
>> reference to patches that deal with them, or are you or is someone else
>> working on them...?
>>
>> Apart from that, I am rather hesitant to take a patch through my tree
>> that not only may cause test failures on platforms that I will not or
>> actually cannot run tests on (like MacOS or Windows), but that actually
>> does introduce new failures as you describe.
>>
>> Well, at least it doesn’t introduce build failures because it appears
>> there is no Python test that’s in the auto group, so I suppose “rather
>> hesitant” is not an “I won’t”.
>>
> 
> Think of it more like this: The failures were always there, but we hid
> them. I'm not "introducing new failures" as such O:-)

That is incorrect.

As I have said, the conceptual problem is that the iotests now run as
part of make check.  As such, allowing auto tests to run on non-Linux
platforms may introduce build failures that I cannot do anything about.

And those are very much new failures.

> I think that I have demonstrated sufficiently that it's not correct to
> prohibit python tests from running on other platforms wholesale, so I'd
> prefer we don't do that anymore.

You have not.

The actual argument to convince me is “This does not affect any tests in
the auto group, so it will not introduce build failures at this time”.

> Further, iotests on FreeBSD already weren't 100% green, so I'm not
> causing a regression in that sense, either.

My problem is twofold:

(1) You claim “Sure, there are failures, but let’s just deal with them”
and then you do not deal with them.  Seems wrong to me.

I’m fine with the argument “Sorry, royal ‘we’.  But it just doesn’t help
anyone to hide the errors.  If someone’s on BSD and wants to run the
iotests, let them.”

That sounds good to me.

(2) Maybe someone adds a Python test in the future that is in auto and
that does not specify Linux as the only supported platform.  Then I send
a pull request and it breaks on macOS.  Now what?  Remove it from auto?
 Blindly put "macOS" in unsupported platforms?

In any case, it’ll be a problem for no good reason.

More on that in the next chunk.

> I'm going to meekly push and ask that we stage this as-is, and when
> something bad happens you can remind me that I wanted this and make me
> do it.

Make you do what?  Deal with the fact that a pull request is rejected
because a test fails on macOS?

This is precisely the kind of problem I already had with adding the
iotests to make check, and I’m already very much not happy about it.
(In that case it was $DISPLAY not being set on Peter’s test system.)


I’ll let you make the deduction of “The problem isn’t allowing the
iotests to run on non-Linux platforms, but the fact that they run in
make check” yourself, so that I no longer feel like I’m the only one who
considers that having been a mistake.

Max

signature.asc
Description: OpenPGP digital signature