qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)
Date: Tue, 22 Nov 2016 14:47:34 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/22/2016 01:41 PM, Paolo Bonzini wrote:
> 
> 
> On 22/11/2016 19:54, Eric Blake wrote:
>>>>>>  DRM DRIVER FOR BOCHS VIRTUAL GPU
>>>>>>  M:      Gerd Hoffmann <address@hidden>
>>>>>> -S:      Odd Fixes
>>>>>> +L:      address@hidden
>>>>
>>>> qemu-devel list already has very high traffic - not sure whether it
>>>> makes much sense to route even more additional patches here. Maybe
>>>> rather create a separate mailing list like address@hidden ?
>> In practice, ALL patches should already be going to qemu-devel, even if
>> they are ALSO going to some other list.  For example, qemu-block and
>> qemu-trivial are definitely cases where we have separate lists, but
>> where posters are reminded to include qemu-devel in cc if they want a
>> patch applied.
> 
> The difference is that these would be kernel patches.

Ah, indeed. I missed the distinction of 'all _qemu_ patches' are already
going to the qemu list, but this is about non-qemu patches.  I guess I
was thrown off because I first read this message as cross-posted onto
the qemu lists, rather than its primary audience of the kernel list.
But it goes to show that when more than one non-overlapping list is cc'd
on an individual patch, it gets harder to tell which list the patch is
meant for, vs. which other lists are just getting it out of courtesy.
So you've just managed to convince me that including qemu-devel on every
driver patch, when qemu.git will not be modified, may indeed be
overkill; when compared to the option of just creating a new dedicated
list for the subset of kernel patches related to qemu drivers.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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