+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@xxxxxxxxxxxxx> >> >> 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@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@xxxxxxxxxx> >> M: Zack Rusin <zackr@xxxxxxxxxx> >> +L: linux-graphics-maintainer@xxxxxxxxxx (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@xxxxxxxxxx, which is an email alias that anyone can post to in order to reach the x86 maintainer community for patch review. I see x86@xxxxxxxxxx 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
