qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL v3 2/6] tests/9pfs: change qtest name prefix to synth


From: Philippe Mathieu-Daudé
Subject: Re: [PULL v3 2/6] tests/9pfs: change qtest name prefix to synth
Date: Wed, 21 Oct 2020 08:15:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

Hi Cristian,

On 10/20/20 1:54 PM, Christian Schoenebeck wrote:
On Dienstag, 20. Oktober 2020 12:00:57 CEST Greg Kurz wrote:
On Tue, 20 Oct 2020 11:43:18 +0200

Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
On Dienstag, 20. Oktober 2020 09:36:10 CEST Philippe Mathieu-Daudé wrote:
On 10/8/20 8:34 PM, Christian Schoenebeck wrote:
All existing 9pfs test cases are using the 'synth' fs driver so far,
which
means they are not accessing real files, but a purely simulated (in
RAM
only) file system.

Let's make this clear by changing the prefix of the individual qtest
case
names from 'fs/' to 'synth/'. That way they'll be easily
distinguishable
from upcoming new 9pfs test cases supposed to be using a different fs
driver.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id:
<e04e75acb849b085c6d6320b2433a15fa935bcff.1602182956.git.qemu_oss@crud
eby
te.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>

Harmless, but don't need to sign twice ;)

Ah, I thought that's the common way, as Greg's PRs contained 2 SOBs as
well, i.e. I thought this was intended to outline the patch author and
submaintainer were the same person.

BTW I actually did not explicitly add the 2nd SOB. It was rather added by
the patchwork client automatically. So maybe it should be fixed in the
client to detect an already existing SOB line? Or am missing something
here?
Yeah this is the reason why my sob appears twice on patches authored by
me, and since this is harmless I never really investigated how to fix
pwclient :)

Well, I would usually offer my 'I can look at it' at this point, but I am
reluctant this time as I assume it will end up as my recently suggested libqos
patches where I did not get any response from the officially assigned
maintainers; not even a simple 'nack'.

I was just watching your contributions and suggested an improvement
because something in your new workflow seems mis-configured (other
maintainers don't have this problem). I didn't asked you to fix a
bug in a different tool. I apologize if I was unclear and you
understood it this way.

Regarding your issue with a different series, I suppose you already
read:
https://wiki.qemu.org/Contribute/SubmitAPatch#If_your_patch_seems_to_have_been_ignored
and
https://wiki.qemu.org/Contribute/SubmitAPatch#Return_the_favor

You'll see that maintenance can be very time consuming, and we are
overcrowded from time to time when there is rush. I doubt maintainers
are ignoring your patches, as most of them try to do their best.
You might help them by reviewing patches for them, so they have time
to process your series.

Regards,

Phil.




reply via email to

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