From: zimoun <zimon.toutoune@gmail.com>
To: Brett Gilio <brettg@gnu.org>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
"Tobias Geerinckx-Rice" <me@tobias.gr>,
"GNU Guix maintainers" <guix-maintainers@gnu.org>,
38846@debbugs.gnu.org
Subject: [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access.
Date: Tue, 7 Jan 2020 12:27:58 +0100 [thread overview]
Message-ID: <CAJ3okZ1WskFa+X9YBgVa5n0h7LtxmZhFiVyvaYFPqixyY5=YzQ@mail.gmail.com> (raw)
In-Reply-To: <87woa486fe.fsf@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 <brettg@gnu.org> wrote:
>
> Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org>
> 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 ‘let's try again later’ 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=38846#71
> I hope this makes sense. Maybe I am being overly nitpicky, I just really
> like clarity. :)
Me too, :-)
All the best,
simon
next prev parent reply other threads:[~2020-01-07 11:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 16:29 [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access Ludovic Courtès
2020-01-01 16:34 ` [bug#38846] [PATCH 1/4] doc: Add "Tracking Bugs and Patches" section Ludovic Courtès
2020-01-01 16:34 ` [bug#38846] [PATCH 2/4] doc: Move "Commit Access" section from 'HACKING' to the manual Ludovic Courtès
2020-01-01 18:08 ` Ricardo Wurmus
2020-01-01 16:34 ` [bug#38846] [PATCH 3/4] doc: Encourage patch review Ludovic Courtès
2020-01-01 18:09 ` Ricardo Wurmus
2020-01-01 16:34 ` [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access Ludovic Courtès
2020-01-01 18:15 ` Ricardo Wurmus
2020-01-02 11:20 ` Ludovic Courtès
2020-01-07 22:36 ` Maxim Cournoyer
2020-01-01 18:51 ` zimoun
2020-01-02 11:53 ` Ludovic Courtès
2020-01-02 18:35 ` zimoun
2020-01-06 9:30 ` Ludovic Courtès
2020-01-02 4:09 ` Brett Gilio
2020-01-02 11:15 ` Ricardo Wurmus
2020-01-02 11:59 ` Ludovic Courtès
2020-01-06 23:29 ` Tobias Geerinckx-Rice via Guix-patches via
2020-01-06 23:34 ` Tobias Geerinckx-Rice via Guix-patches via
2020-01-07 0:19 ` Brett Gilio
2020-01-07 11:27 ` zimoun [this message]
2020-01-09 22:39 ` bug#38846: " Ludovic Courtès
2020-01-01 18:07 ` [bug#38846] [PATCH 1/4] doc: Add "Tracking Bugs and Patches" section Ricardo Wurmus
2020-01-01 18:18 ` zimoun
2020-01-02 11:51 ` Ludovic Courtès
2020-01-02 18:40 ` zimoun
2020-01-01 18:37 ` [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access Ricardo Wurmus
2020-01-06 13:13 ` Ludovic Courtès
2020-01-07 22:50 ` Marius Bakke
2020-01-06 21:44 ` zimoun
2020-01-07 11:17 ` Ludovic Courtès
2020-01-09 22:05 ` Ludovic Courtès
2020-01-10 15:49 ` zimoun
2020-01-13 10:01 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ3okZ1WskFa+X9YBgVa5n0h7LtxmZhFiVyvaYFPqixyY5=YzQ@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=38846@debbugs.gnu.org \
--cc=brettg@gnu.org \
--cc=guix-maintainers@gnu.org \
--cc=ludo@gnu.org \
--cc=me@tobias.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).