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

Lynne dev at lynne.ee
Mon Jan 30 01:14:58 EET 2023


Dec 18, 2022, 07:31 by dev at lynne.ee:

> Dec 16, 2022, 23:05 by michael at niedermayer.cc:
>
>> On Fri, Dec 16, 2022 at 12:26:58AM +0100, Lynne wrote:
>>
>>> Dec 15, 2022, 20:34 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 remember no such change.
>>> > What i do remember is really long ago trying to push people toward pushing in
>>> > their own repository and sending pull requests similar to the kernel. But this
>>> > was not popular so i droped the idea.
>>> >
>>> > Whereever code is maintained teh maintainer should have write access to that
>>> > place other things become inconvenient quickly.
>>> >
>>> > maintainers who cannot change the code they maintain should stay an exception
>>> >
>>>
>>> This is exactly what changed. Before, maintainers who didn't get push
>>> access was the norm, not the standard.
>>>
>>> Regardless, if you agree with the patch, I see no reason to continue discussing this.
>>>
>>
>> I see the need to reach some approximate consensus on the past because making
>> decissions should not be based on misremembering things.
>>
>> I see that in 2015 the GSOC students who got added to MAINTAINERs
>> also got write access in 2015.
>> and IIRC x264 had a similar policy at the time where students would be treated like
>> any other developer and have equal access.
>>
>> I use this as an example because several of these students came and left after
>> their project and still got write access.
>>
>> Maybe all our memories are not 100% exact after so many years but I think you misremember
>> if you think we had alot of maintainers who did not have the same acccess
>> there where some exceptions but they where few.
>> Also some people like the students in the example above, left they did not use their write
>> access so maybe people forgot they had write access
>>
>
> I don't object to students having push access and being treated like developers,
> I think that's beneficial. I don't mind them leaving and still having write access either.
> My concern are the drive-by developers who drop a patchset and want to get
> added to MAINTAINERS to voice their opinions on future patches for their code.
> Most of them do not want push access, they just want to be consulted if their code
> has any changes outstanding.
>
> Regardless of what you think the policy has been or is, most developers I've spoken
> to about this see the MAINTAINERS list as an informative list, not as a write
> access request, and I think so as well. This patch just makes it explicit whether
> someone wants write access or just maintainership.
>

Pushing this in 3 days unless anyone objects.


More information about the ffmpeg-devel mailing list