On 07.10.19 18:28, Thomas Huth wrote:
> On 07/10/2019 15.11, Thomas Huth wrote:
>> On 07/10/2019 14.52, Max Reitz wrote:
>>> On 07.10.19 14:16, Thomas Huth wrote:
On 04/10/2019 14.44, Max Reitz wrote:
> On 04.10.19 12:19, Kevin Wolf wrote:
>> Am 02.10.2019 um 19:47 hat Max Reitz geschr
On 07/10/2019 15.11, Thomas Huth wrote:
> On 07/10/2019 14.52, Max Reitz wrote:
>> On 07.10.19 14:16, Thomas Huth wrote:
>>> On 04/10/2019 14.44, Max Reitz wrote:
On 04.10.19 12:19, Kevin Wolf wrote:
> Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
>> On 02.10.19 18:44, Kevin Wolf w
On 07/10/2019 14.52, Max Reitz wrote:
> On 07.10.19 14:16, Thomas Huth wrote:
>> On 04/10/2019 14.44, Max Reitz wrote:
>>> On 04.10.19 12:19, Kevin Wolf wrote:
Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
> On 02.10.19 18:44, Kevin Wolf wrote:
>> Am 02.10.2019 um 13:57 hat Max Rei
On 07.10.19 14:16, Thomas Huth wrote:
> On 04/10/2019 14.44, Max Reitz wrote:
>> On 04.10.19 12:19, Kevin Wolf wrote:
>>> Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
On 02.10.19 18:44, Kevin Wolf wrote:
> Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
>> It usually worked fine
On Mon, 7 Oct 2019 at 13:32, Thomas Huth wrote:
> On 04/10/2019 14.44, Max Reitz wrote:
> > Whenever make check fails, it’s urgent. Without iotests running in make
> > check, we had some time to sort the situation out. That’s no longer the
> > case.
> >
> > That means we need to take care of eve
On 04/10/2019 14.44, Max Reitz wrote:
> On 04.10.19 12:19, Kevin Wolf wrote:
>> Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
>>> On 02.10.19 18:44, Kevin Wolf wrote:
Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
> It usually worked fine for me because it’s rather rare that non-blo
On 04.10.19 16:05, Peter Maydell wrote:
> On Fri, 4 Oct 2019 at 14:50, Max Reitz wrote:
>> On 04.10.19 15:16, Peter Maydell wrote:
>>> 'make check' does have the restriction
>>> that we don't want the tests to take too long to run, but in
>>> general the block layer should be running some reasonab
On Fri, 4 Oct 2019 at 14:50, Max Reitz wrote:
> On 04.10.19 15:16, Peter Maydell wrote:
> > 'make check' does have the restriction
> > that we don't want the tests to take too long to run, but in
> > general the block layer should be running some reasonable subset
> > of tests in the project's sta
On 04.10.19 15:16, Peter Maydell wrote:
> On Fri, 4 Oct 2019 at 13:45, Max Reitz wrote:
>>> In the end, I don't care what code these patches touched. I do an
>>> innocent git pull, and when I finally see that it's master that breaks
>>> iotests and not my patches on top of it, I'm annoyed.
>>
>> H
On Fri, 4 Oct 2019 at 13:45, Max Reitz wrote:
> > In the end, I don't care what code these patches touched. I do an
> > innocent git pull, and when I finally see that it's master that breaks
> > iotests and not my patches on top of it, I'm annoyed.
>
> Hm. Part of my point was that this still hap
On 04.10.19 12:19, Kevin Wolf wrote:
> Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
>> On 02.10.19 18:44, Kevin Wolf wrote:
>>> Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
It usually worked fine for me because it’s rather rare that non-block
patches broke the iotests.
>>>
>>> I
Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
> On 02.10.19 18:44, Kevin Wolf wrote:
> > Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
> >> It usually worked fine for me because it’s rather rare that non-block
> >> patches broke the iotests.
> >
> > I disagree. It happened all the time tha
On 10/1/19 2:44 PM, Max Reitz wrote:
> 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
On 02/10/2019 18.44, Kevin Wolf wrote:
> Not sure where in this thread to reply, but since my name is mentioned
> in this mail, it might at least be not the worst one.
>
> Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
>> On 02.10.19 06:46, Thomas Huth wrote:
>>> On 01/10/2019 20.44, Max Reitz
On 02.10.19 18:44, Kevin Wolf wrote:
> Not sure where in this thread to reply, but since my name is mentioned
> in this mail, it might at least be not the worst one.
>
> Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
>> On 02.10.19 06:46, Thomas Huth wrote:
>>> On 01/10/2019 20.44, Max Reitz wr
Not sure where in this thread to reply, but since my name is mentioned
in this mail, it might at least be not the worst one.
Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
> On 02.10.19 06:46, Thomas Huth wrote:
> > On 01/10/2019 20.44, Max Reitz wrote:
> > [...]
> >> As I have said, the concep
On 02/10/2019 15.36, Max Reitz wrote:
[...]
> 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?
Yes, I think that might be an option... Since many developers are
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 aga
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
On 02.10.19 06:46, Thomas Huth wrote:
> On 01/10/2019 20.44, Max Reitz wrote:
> [...]
>> 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
On 01/10/2019 20.44, Max Reitz wrote:
[...]
> 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.
Well, simply run "make vm-build-open
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 specif
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
>>
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
>>
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
18.09.2019 2: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 p
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
27 matches
Mail list logo
