[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Make 'uri' optional for migrate QAPI
From: |
Michael Tokarev |
Subject: |
Re: [PATCH] Make 'uri' optional for migrate QAPI |
Date: |
Tue, 30 Jan 2024 09:45:26 +0300 |
User-agent: |
Mozilla Thunderbird |
30.01.2024 04:35, Peter Xu:
..
This seems like a stable material too, - please let me know if it is not.
Yes it is. I used to be more careful on copying stable at least in the
commit message when I post patches, but forgot to do so when start picking
up..
Note that it's already merged in master 57fd4b4e10, while there should be a
test case to land later when ready (which won't need to copy stable).
I already picked it up from master yesterday, --
https://gitlab.com/mjt0k/qemu/-/commits/staging-8.2/ . Sometimes I pick up
the test cases too, especially (not in this case) when the actual change
makes existing tests to fail. And yes, I've seen subsequent discussion
in the original thread (to which I replied) about adding the test case.
Since at it, just to double check how stable works for us: as long as the
commit has "Cc: qemu-stable@nongnu.org" when merge should work, even
without the need to reply the patch copying stable list, am I right?
Well, basically, yes. When you send a pull request with a patch which
has Cc: qemu-stable@, it will be Cc'd there by git send-email already.
Also, sometimes I scan all commits applied to master grepping for
Fixes:/Resolves: and similar patterns, and check if the change found
this way is relevant for stable or not, - but obviously this is much
less reliable (compared with when the actual patch author who understands
the situation much better marks the change explicitly) and often
requires extra confirmation round-trip. Cc'ing qemu-stable@ in the
middle of discussion in qemu-devel@ will do the trick too. The key
here is to mark the changes *somehow*.
My own work here is based on my local qemu-stable mailbox, plus the
commits scanning I mention above.
Thanks,
/mjt