[FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access

[Lynne]

Jan 30, 2023, 17:49 by michael at niedermayer.cc:

> On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote:
>
>> This list is incomplete, and just contains those I could see
>> while looking at the recent git log. If it looks like I've forgotten you, I definitely haven't!
>> We may complete the list at a later date.
>>
>> This makes it such that those who add themselves to MAINTAINERS do not
>> get push access by default, but rather, they have to request it
>> explicitly in a different commit. This used to be the situation
>> before it was changed at the start of this year and is pretty much what
>> everyone expects.
>>
>> Patch attached.
>>
>> MAINTAINERS |   15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>> 6a083061d75f6655771bde377f96aadad19b21c6  0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch
>> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001
>> From: Lynne <dev at lynne.ee>
>> Date: Thu, 15 Dec 2022 02:05:00 +0100
>> Subject: [PATCH] MAINTAINERS: add a separate list for those with push access
>>
>> This list is incomplete, and just contains those I could remember
>> while looking at the recent git log.
>> We may complete the list at a later date.
>>
>> This makes it such that those who add themselves to MAINTAINERS do not
>> get push access by default, but rather, they have to request it
>> explicitly in a different commit. This used to be the situation
>> before it was changed at the start of this year.
>>
>
> I dont object to you adding a list of people with commit acccess though i
> dont think its needed or that useful.
> But adding a list that is incomplete, sorted in a odd way and doing so in a
> commit that states a past rule which i dont think was true, seems not
> ideal
>
> ATM there are I think 117 keys that have write access (some may belong to
> the same developers) and also over 100 maintainers in that MAINTAINERs file
> I think. I didnt try to count them too precisely. But the numbers are not
> that disimilar. The added list is quite abit more different
>

My intention was to make this complete after it's accepted (or not, if
someone doesn't want to be known for having push access).


> Also iam not sure this commit will change that much. People who do not want
> write access neither before nor afterwards will not send a ssh key so wont get
> write access. And people who want write access will push for it and
> probably noone will object. Theres the between people who dont push for
> it and noone else would push either they might no longer receive write
> access. Iam not sure if that is better.
>
> It makes things more involved but whats really bad is that this extra
> step is mainly in your mind, its not docuemnted.
> Do i add someone to that new list when i give him write access or do
> i give someone write access when a patch adding her is approved. Or do
> i just ignore that list because its incomplete anyway ?
>
> I assume the intend is the 2nd one but How would a contributor know
> to add herself to that list and what about people who are quite humble
> and who would not push for it yet at the same time would benefit from
> write access ?
>

How would anyone know to maintain something they should add themselves
to the list of maintainers?
A second list of those with push access doesn't add more roadblocks, it's
just a separate list, that's all. You wouldn't have to add yourself to maintainers
to get push access if you don't want to.
As for those humble, I do see your point, but it's a one-line diff change,
and it can be done in the same commit adding yourself to maintainers,
it's not a 2-page personal statement about values.


> ATM every maintainer automatically receives the right for write access
> After this patch its made more difficult, i cant just post a patch adding
> random people either Someone would have to convince them first that they
> should post a patch to add themselfs. 
>
> So what i really dislike on this change is the potential stumbling blocks
> it throws before new developers.
>
> Its important that one has write access to the repository one works in
> In FFmpeg that work happens on git master so write access to that is
> important for anyone actively working on it.
> In other places work and review might happen in developers own repositories
> and they get merged regularly. In that case write access to master is not needed
>