From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:40894) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ion2m-00046m-8z for guix-patches@gnu.org; Tue, 07 Jan 2020 06:29:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ion2k-0000qB-NZ for guix-patches@gnu.org; Tue, 07 Jan 2020 06:29:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41427) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ion2k-0000q5-KW for guix-patches@gnu.org; Tue, 07 Jan 2020 06:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ion2k-00081C-Hq for guix-patches@gnu.org; Tue, 07 Jan 2020 06:29:02 -0500 Subject: [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access. Resent-Message-ID: MIME-Version: 1.0 References: <20200101163446.5132-1-ludo@gnu.org> <20200101163446.5132-4-ludo@gnu.org> <87a770dv07.fsf@nckx> <87woa486fe.fsf@gnu.org> In-Reply-To: <87woa486fe.fsf@gnu.org> From: zimoun Date: Tue, 7 Jan 2020 12:27:58 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Brett Gilio Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Tobias Geerinckx-Rice , GNU Guix maintainers , 38846@debbugs.gnu.org Hi, My end-user opinion does not matter. But the transparency is good. :-) On Tue, 7 Jan 2020 at 01:19, Brett Gilio wrote: > > Tobias Geerinckx-Rice via Guix-patches via > writes: > > > Probably just me, but this glosses over maintainer approval just a bit > > too deftly, and that even with 3 signed referrals commit access isn't > > guaranteed, just extremely likely. > > > > Unless that will actually change, I think we should briefly mention it > > as well. People react worse to =E2=80=98let's try again later=E2=80=99= when they > > think they've already passed. Understandably so. [...] > This is definitely not just you. I felt similarly, as per a previous > email on the matter where I suggested that it be 3 commiters and 1 > maintainer. But that process turned out to be redundant, if not > completely superfluous by Ricardo's mention of how the process is likely > to change in the future with a different integration model. I am not native English speaker so maybe I misread. From my understanding, the proposal clarifies how the access is granted. Currently, only the maintainers grant; from what I have observed, it is more because of historical reasons than an explicit model. The new integration model proposes to enforce the trust and goes to reduce/distribute the "power" of maintainers -- which is good IMHO. Therefore, the maintainers trust the current committers, and if 3 committers approve, why should 1 maintainer reject the applicant? It is a chain of trust. > Regardless, I hear your point. I also think that getting refused after > achieving three referrals is a hard point. I think it should be > documented clearly that the mainters have the final say. I do not see why. If 3 referrals vouch an applicant and 1 maintainer refuses, then there is an issue elsewhere. The chain of trust is broken and it means that the project is not healthy. > Additionally, and this is just a point for my part, depending on what > kind of merit we are taking for credence in a committer making a > referral, should we only consider committers who have worked closely > with the person requesting commit access, or is somebody who has > reviewed and seen their patches in passing also a viable subject? As an end-user, I do not want to pull "bad" code; which means not GNU compliant. And a rule of thumb usually is: when you (committer) are annoyed to review patches because you know that you would not do better yourself; concretely, significant contributions with no final tweaks. > For example, I have been asked a few times by people to push patches for > them over IRC, but their patches were unrelated to software I use / > would use / know how to approach (examples being GNOME). So, I kindly > refused to push their patch citing that I do not feel comfortable in > knowledge to understand the ramifications of their > patches. Hypothetically, if such a person approached me in the future > and asked for a commit access referral, since I had not worked closely > with them what kind of weight would be referral hold? The bottleneck is the review. Well, I have tried to point out this here [1]= . Sometime ago, "maintainer" of submodule had been discussed. For example, one could imagine that the commit access comes with the "responsibility" to take care of a submodule; with great power comes great responsibility. ;-) [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38846#71 > I hope this makes sense. Maybe I am being overly nitpicky, I just really > like clarity. :) Me too, :-) All the best, simon