Re: [PATCH v3 3/3] MAINTAINERS: Mark VMware mailing list entries as email aliases
From: Srivatsa S. Bhat
Date: Fri Nov 12 2021 - 12:50:55 EST
[ Resending since my previous reply didn't reach the mailing lists. ]
On 11/11/21 5:55 AM, Jakub Kicinski wrote:
> On Wed, 10 Nov 2021 21:19:53 -0800 Joe Perches wrote:
>> On Wed, 2021-11-10 at 17:39 -0800, Jakub Kicinski wrote:
>>> On Wed, 10 Nov 2021 12:09:06 -0800 Srivatsa S. Bhat wrote:
>>>> DRM DRIVER FOR VMWARE VIRTUAL GPU
>>>> -M: "VMware Graphics" <linux-graphics-maintainer@xxxxxxxxxx>
>>>> M: Zack Rusin <zackr@xxxxxxxxxx>
>>>> +R: VMware Graphics Reviewers <linux-graphics-maintainer@xxxxxxxxxx>
>>>> L: dri-devel@xxxxxxxxxxxxxxxxxxxxx
>>>> S: Supported
>>>> T: git git://anongit.freedesktop.org/drm/drm-misc
>>>
>>> It'd be preferable for these corporate entries to be marked or
>>> otherwise distinguishable so that we can ignore them when we try
>>> to purge MAINTAINERS from developers who stopped participating.
>>>
>>> These addresses will never show up in a commit tag which is normally
>>> sign of inactivity.
>>
>> Funny.
>>
>> The link below is from over 5 years ago.
>>
>> https://lore.kernel.org/lkml/1472081625.3746.217.camel@xxxxxxxxxxx/
>>
>> Almost all of those entries are still in MAINTAINERS.
>>
>> I think the concept of purging is a non-issue.
>
> I cleaned networking in January and intend to do it again in 2 months.
> See:
>
> 054c4610bd05 MAINTAINERS: dccp: move Gerrit Renker to CREDITS
> 4f3786e01194 MAINTAINERS: ipvs: move Wensong Zhang to CREDITS
> 0e4ed0b62b5a MAINTAINERS: tls: move Aviad to CREDITS
> c41efbf2ad56 MAINTAINERS: ena: remove Zorik Machulsky from reviewers
> 5e62d124f75a MAINTAINERS: vrf: move Shrijeet to CREDITS
> 09cd3f4683a9 MAINTAINERS: net: move Alexey Kuznetsov to CREDITS
> 93089de91e85 MAINTAINERS: altx: move Jay Cliburn to CREDITS
> 8b0f64b113d6 MAINTAINERS: remove names from mailing list maintainers
>
I'm assuming the purging is not totally automated, is it? As long as
the entries are informative to a human reader, it should be possible
to skip the relevant ones when purging inactive entries.
I believe this patch makes the situation better than it is currently
(at least for the human reader), by marking lists without public
read-access in a format that is more appropriate. In the future, we
could perhaps improve on it to ease automation too, but for now I
think it is worthwhile to merge this change (unless there are strong
objections or better alternatives that everyone agrees on).
Regards,
Srivatsa