From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:40864) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iocaN-0008DE-5d for guix-patches@gnu.org; Mon, 06 Jan 2020 19:19:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iocaL-0002ux-Uz for guix-patches@gnu.org; Mon, 06 Jan 2020 19:19:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41069) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iocaL-0002ut-S3 for guix-patches@gnu.org; Mon, 06 Jan 2020 19:19:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iocaL-0006v3-ON for guix-patches@gnu.org; Mon, 06 Jan 2020 19:19:01 -0500 Subject: [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access. Resent-Message-ID: Received: from eggs.gnu.org ([2001:470:142:3::10]:40346) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iocaD-00085k-FR for guix-patches@gnu.org; Mon, 06 Jan 2020 19:18:55 -0500 From: Brett Gilio References: <20200101163446.5132-1-ludo@gnu.org> <20200101163446.5132-4-ludo@gnu.org> <87a770dv07.fsf@nckx> Date: Mon, 06 Jan 2020 18:19:01 -0600 In-Reply-To: <87a770dv07.fsf@nckx> (Tobias Geerinckx-Rice via Guix-patches via's message of "Tue, 07 Jan 2020 00:29:12 +0100") Message-ID: <87woa486fe.fsf@gnu.org> MIME-Version: 1.0 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: 38846@debbugs.gnu.org Cc: ludo@gnu.org, me@tobias.gr, guix-maintainers@gnu.org 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 w= hen they > think they've already passed. Understandably so. Hi Tobias, 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. 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. 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? 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? I hope this makes sense. Maybe I am being overly nitpicky, I just really like clarity. :) --=20 Brett M. Gilio GNU Guix, Contributor | GNU Project, Webmaster [DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]