qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [PATCH v5 1/5] iotests: remove 'linux' from default supported platforms
Date: Wed, 2 Oct 2019 15:36:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0

On 02.10.19 15:11, Thomas Huth wrote:
> On 02/10/2019 13.57, Max Reitz wrote:
>> On 02.10.19 06:46, Thomas Huth wrote:
>>> [...]
>>> Max, I can understand that you are a little bit annoyed that this "make
>>> check with iotests" caused some extra hurdles for you. But honestly,
>>> removing that again would be quite egoistic by you. Try to put yourself
>>> into the position of a "normal", non-blocklayer-maintainer QEMU
>>> developer. For me, iotests were a *constant* source of frustration.
>>> Often, when I ran them on top of my latest and greatest patches, to
>>> check whether I caused a regression, the iotests simply failed. Then I
>>> had to start debugging - did my patches cause the break, or is "master"
>>> broken, too? In almost all cases, there was an issue in the master
>>> branch already, either because they were failing on s390x, or because I
>>> was using ext4 instead of xfs, or because I was using an older distro
>>> than you, etc... . So while the iotests likely worked fine for the
>>> limited set of systems that you, Kevin and the other hard-core block
>>> layer developers are using, it's constantly broken for everybody else
>>> who is not using the very same setup as you. The only way of *not*
>>> getting upset about the iotests was to simply completely *ignore* them.
>>> Is it that what you want?
>>
>> It usually worked fine for me because it’s rather rare that non-block
>> patches broke the iotests.
>>
>> I have to admit I actually didn’t think of other people wanting to run
>> the iotests; but to be honest, your mail doesn’t sound like you want to
>> run the iotests either.
> 
> I *want* to run them. Occasionally - when I have new patches that might
> affect anything related to the block layer. But then I don't want to be
> in the situation where I first have to debug multiple other problems
> with the iotests first that are not related to my new patches.

OK.

>> (The reason I didn’t think of it is because non-block patches rarely
>> break them, so I wouldn’t run the iotests if I were a non-block
>> maintainer.  Sorry.)
> 
> Well, "rarely" is relative. They've been broken *completely* two times
> in the 4.1 development time frame, and IIRC at least once in the 4.0
> time frame.

Hm, OK.  So my memory is just shot.

> [...]
>> Maybe my main problem is that I feel like now I have to deal with all of
>> the fallout, even though adding the iotests to make check wasn’t my idea
>> and neither me nor Kevin ever consented.  (I don’t know whether Kevin
>> consented implicitly, but I don’t see his name in bdd95e47844f2d8b.)
>>
>> You can’t just give me more responsibility without my consent and then
>> call me egoistic for not liking it.
> 
> Ok, sorry for that. I guess one part of my frustration was also that the
> patches to enable the iotests during "make check" have been on the list
> for weeks - or rather months - and I never ever got much feedback from
> you or Kevin on them.
I think that’s for two reasons:

(1) The time line in the block layer is unfortunately apparently
different from what you’re used to.  Or, rather, fortunately for you.
It isn’t too rare for me to have patches up for a year or more.

(2) We’ve had discussions on this before and the result was always the
same.  Yes, we’d like to run the iotests as part of make check, but we
can’t imagine it would work right now (where “right now” is whenever we
have the discussion).

So as for me, I felt bad about plainly saying “no”.  But I cannot say
“yes” either.  You’re right that I should’ve said something.  There are
more words than “yes” and “no”.  Sorry again.

I can imagine I had hoped Kevin would speak up (and thus take
responsibility) or you’d become so annoyed with our silence that you’d
angrily reach out to us and I’d have to do something.  (Which is a
horrible attitude, I realize that.)
I do remember that I didn’t expect that you’d just find someone else to
merge the patch.  That took me by surprise.

> If you told me right in the beginning about your
> concerns, we would not be at this point now. Also partly my bad, I
> guess, since I could have reached out to you on IRC to discuss it, but
> at that point in time, I rather thought that you just don't really care.
> Thus it's good to have some conversation now, helps a lot to understand
> the different expectations. Maybe we can also have a discussion about
> this at KVM forum, I think it's easier to clarify some points of view
> verbally there instead of using mails.

Well, I won’t be at KVM Forum, unfortunately.

>>> Or maybe let me phrase it differently: Do you consider the iotests as
>>> something that is more or less "private" to the hard-core block layer
>>> developers, and it's ok if others completely ignore them and break them
>>> by accident (and you also don't expect the normal developers to fix the
>>> iotests afterwards)?
>>
>> Well, that’s how it’s always worked, and that didn’t frustrate me.
> 
> Ok ... you're the maintainer, so if that's really the way you prefer, I
> can send a patch to remove the iotests from "make check" again.
> 
>> Honestly, it looks to me like you don’t even want to run the iotests.  I
>> interpret most of what you’ve written as:
>>
>> - I don’t want to not run the iotests, because then people will hit me
>>   for making them fail.
>>
>> - But they fail all the time, so I always need a baseline for what is
>>   expected to sometimes fail and what isn’t.  That’s very annoying.
>>   Let’s introduce a baseline in the form of auto/qcow2, and then let
>>   everyone verify that it works.
>>
>> So to me it looks like we’ve just added all tests that never fail to
>> auto.  But if they never fail, then it’s like we haven’t run the tests
>> at all.
> 
> I disagree. First, the complete iotest failures that have been merged
> during the 4.1 development time frame to the master branch would have
> been prevented, I think, so it's certainly not that "they never fail".
> 
> Second, yes, the basic idea was to start with a small set of tests in
> the auto group which was already working, and then to increase that set
> over time, once other tests run more stable, too. But you know the
> iotests better than me, if you think that most of them can hardly
> brought into the right shape, then this was likely just wishful thinking
> by me.

I know that one never knows which test turns out to be unstable next.

>> You have to decide: Either let me deal with the problems, but then I
>> have every right to be egoistic about it – or you help me deal with them.
> 
> Since I'm not assigned to the block layer, I could only help
> occasionally, so that's likely not enough for solving your frustration.
> Thus I'll send a patch to remove the iotests from "make check" again.

OK.  Maybe someone else will step up once they see the patch.

Or can we have some middle ground?  Something that runs on some CI
systems (and notifies me and others) but won’t result in pull requests
being rejected or cause make check failures?

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]