Dec 16, 2022, 23:05 by mich...@niedermayer.cc: > On Fri, Dec 16, 2022 at 12:26:58AM +0100, Lynne wrote: > >> Dec 15, 2022, 20:34 by mich...@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 <d...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
