From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 2A2AC44B8E for ; Tue, 7 Feb 2023 01:20:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 044F368BDD5; Tue, 7 Feb 2023 03:20:36 +0200 (EET) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9C4BD68BBC9 for ; Tue, 7 Feb 2023 03:20:29 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 944FF100003 for ; Tue, 7 Feb 2023 01:20:28 +0000 (UTC) Date: Tue, 7 Feb 2023 02:20:27 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230207012027.GQ1949656@pb2> References: <20230130164931.GJ1949656@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6362943779966501194==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6362943779966501194== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tJBhac6oLx0WQ9O+" Content-Disposition: inline --tJBhac6oLx0WQ9O+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 06, 2023 at 01:10:06PM +0100, Lynne wrote: > Jan 30, 2023, 20:03 by dev@lynne.ee: >=20 > > Jan 30, 2023, 17:49 by michael@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 wh= at > >>> everyone expects. > >>> > >>> Patch attached. > >>> > >>> MAINTAINERS | 15 +++++++++++++++ > >>> 1 file changed, 15 insertions(+) > >>> 6a083061d75f6655771bde377f96aadad19b21c6 0001-MAINTAINERS-add-a-sepa= rate-list-for-those-with-push-.patch > >>> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001 > >>> From: Lynne > >>> 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 thoug= h 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 chan= ge, > > 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 add= ing > >> random people either Someone would have to convince them first that th= ey > >> should post a patch to add themselfs.=20 > >> > >> So what i really dislike on this change is the potential stumbling blo= cks > >> 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 reposit= ories > >> and they get merged regularly. In that case write access to master is = not needed > >> >=20 > At the FOSDEM meeting yesterday, everyone there agreed that while it's not > perfect, it's a step in the right direction, and we should merge this. Well, i was not there and i do not know what was said, also i dont think the issues have been addressed The commit message implies a past policy which is not correct and commit messages can not be corrected later so it should be corrected first. Also if the intend is that people need to add themselfs to the git list in the MAINTAINERS file to get write access then this should be written in the MAINTAINERS file and also somewhete in the policy, maybe the patch checklist. implied only by a commit message, i think it will be missed Still i think this change is not a good idea. I think maintainership and git access should be closely tied together. Not choosen one by one Just to clarify, i dont mind at all to docuemnt properly who has git access exactly (which may differ slightly) but the idea someone would be a active maintainer and work / want to work but not be given git access really feels like a bad idea to me. Also this whole makes the process more complex thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answe= r. --tJBhac6oLx0WQ9O+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY+GnVAAKCRBhHseHBAsP q5/WAJoDLT6pq1Z9J59e7DVW0Ym++4j8OACdFTjpyjWdiiHaxZNpf163Z2DbwC4= =3AKq -----END PGP SIGNATURE----- --tJBhac6oLx0WQ9O+-- --===============6362943779966501194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============6362943779966501194==--