Re: [Qemu-devel] [PATCH v4] monitor: allow device_del to accept QOM paths

[Eric Blake]

On 09/14/2015 10:49 AM, Programmingkid wrote:
>> But you are worrying about nothing; although Kevin is waiting for a v3,
>> he has already mentioned on v2 that he is ready to queue auto-generation
>> once it works:
>> https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg00877.html
> 
> It has been a while since Kevin asked for a version 3. I wonder if the author
> of the patch knows about the version 3 request. 

You're worrying about nothing (not to mention worrying on the wrong
thread).  The Red Hat engineers (including Jeff [as author of the thread
you are worrying about], Kevin [as the maintainer that plans to take
that patch], Paolo, Markus, myself [each listed on cc on this thread],
and several others on the list) are fairly good about communicating with
one another whenever a piece of work is blocking on someone else's
actions, even if some of that communication occurs on private IRC
channels instead of the list (to cut down on list traffic that is not as
interesting to others).  And from personal experience, frequent
contributors on this list can be trusted to revise their patches as
requested, without having to be prodded.  And Red Hat has no monopoly on
frequent contributors; Andreas [who is also on cc for this thread] is
yet another example, out of many, of someone that will follow through
with addressing review comments.

Remember, just because patches don't land in 24 hours doesn't mean they
aren't happening.  Also, engineers may have multiple things on their
plate, so while they will eventually get to responding to review
comments, they may have other higher-priority tasks to attend to first.
 The 2.5 release freeze is still several weeks off, and it doesn't
matter whether a patch lands today or in two weeks, if it is aiming to
make it into the 2.5 release.  Please exercise some patience.  And while
pings are sometimes appropriate, it is also reasonable to wait a least a
week from the last activity on a thread, and then to ping on the thread
you are worried about, rather than to side-track an unrelated thread
where you may not even be reaching the right people.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature