[PATCH 2/2] MAINTAINERS: Mark VMware mailing list entries as private

[Srivatsa S. Bhat]

+Greg, Thomas

Hi Joe,

On 11/8/21 3:37 PM, Joe Perches wrote:
> On Mon, 2021-11-08 at 12:30 -0800, Srivatsa S. Bhat wrote:
>> From: Srivatsa S. Bhat (VMware) <srivatsa at csail.mit.edu>
>>
>> VMware mailing lists in the MAINTAINERS file are private lists meant
>> for VMware-internal review/notification for patches to the respective
>> subsystems. So, in an earlier discussion [1][2], it was recommended to
>> mark them as such. Update all the remaining VMware mailing list
>> references to use that format -- "L: list at address (private)".
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> @@ -6134,8 +6134,8 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
>>  F:	drivers/gpu/drm/vboxvideo/
>>  
>>  DRM DRIVER FOR VMWARE VIRTUAL GPU
>> -M:	"VMware Graphics" <linux-graphics-maintainer at vmware.com>
>>  M:	Zack Rusin <zackr at vmware.com>
>> +L:	linux-graphics-maintainer at vmware.com (private)
> 
> This MAINTAINERS file is for _public_ use, marking something
> non-public isn't useful.
> 
> private makes no sense and likely these L: entries shouldn't exist.
> 
> 

Well, the public can send messages to this list, but membership is
restricted.

In many ways, I believe this is similar to x86 at kernel.org, which is an
email alias that anyone can post to in order to reach the x86
maintainer community for patch review. I see x86 at kernel.org listed as
both L: and M: in the MAINTAINERS file, among different entries.

Although the @vmware list ids refer to VMware-internal mailing lists
as opposed to email aliases, they serve a very similar purpose -- to
inform VMware folks about patches to the relevant subsystems.

Is there a consensus on how such lists should be specified? One
suggestion (from Greg in the email thread referenced above) was to
mark it as private, which is what this patch does. Maybe we can find a
better alternative?

How about specifying such lists using M: (indicating that this address
can be used to reach maintainers), as long as that is not the only M:
entry for a given subsystem (i.e., it includes real people's email id
as well)? I think that would address Greg's primary objection too from
that other thread (related to personal responsibility as maintainers).

Regards,
Srivatsa