From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: GNU Guix maintainers <guix-maintainers@gnu.org>, 38846@debbugs.gnu.org
Subject: [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access
Date: Mon, 6 Jan 2020 22:44:38 +0100 [thread overview]
Message-ID: <CAJ3okZ2M1iMJJUuXJxgdHmvm4zTEMq_KQgwAM_bdWGr+86ha8A@mail.gmail.com> (raw)
In-Reply-To: <20200101162945.4946-1-ludo@gnu.org>
Hi,
On Wed, 1 Jan 2020 at 17:31, Ludovic Courtès <ludo@gnu.org> wrote:
> 1. Move text from ‘HACKING’ to ‘doc/contributing.texi’.
>
> 2. Encourage patch review for committers.
>
> 3. Add a tentative policy for granting commit access (the last
> patch of this series).
>
> I expect #1 and #2 to be uncontroversial, but I’d like feedback on #3!
>
> So far, we’ve been giving commit access in a very ad-hoc fashion.
> Often it was Ricardo or myself who ended up taking care of that,
> even though other people have admin rights on Savannah to add/remove
> members.
>
> We briefly discussed it among maintainers after the maintainer
> collective expanded, and it seems to me that perhaps now is a good time
> to formalize things a bit—to clarify what contributors may expect and
> to increase transparency. Hence this proposal of a simple co-optation
> policy.
>
> As you know, Chris Baines has been working towards automated testing
> of submitted patches. One of the goals is to allow part of the
> QA to be automated, such that, eventually, approved merges could be
> automated. In that spirit, we would have an incentive to not add more
> committers (probably also a good thing security-wise). That’s why I
> added a note on this topic.
>
> What do people think?
Personally, I find this proposal nice. As I already said when
commenting on each patch. :-)
However, let point 2 minor weak points for further discussions:
a- if the number of committers with access is more or less fixed,
then access could be transferred (less active, less time, less
motivation, etc.);
and b- the bottleneck is the patch review (even if it should be
improved in the future with the Guix Data Service).
Well, a- is more about human relationship, hard to fix. However, we
should work on b- but how? What does it mean "encourage patch review"?
Candy or beer at Guix Days? ;-)
For example, this patch [1] has fallen in the crack. Or this one [2]
or this other one [3].
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31973
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33041
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33318
From the v1.0.1 to now, the repartition of committers which are not the authors:
361
78
65
61
59
54
52
47
44
43
37
21 (x2)
11
9
8
7 (x2)
6
5 (x3)
4 (x2)
3
2 (x3)
1 (x3)
which should be compared to the number of commits per author also
committer (first 10):
1463
1162
886
670
618
335
204
166
161
150
--8<---------------cut here---------------start------------->8---
# committer and not the author
git log v1.0.1..origin/HEAD --pretty=format:"%an~%cn" \
| awk -F '~' '{if ($1 != $2) {++cnt; print "#"$2};}' \
| sort \
| uniq -c \
| sort -nr \
| cut -f1 -d'#'
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
# committer and the author
git log v1.0.1..origin/HEAD --pretty=format:"%an~%cn" \
| awk -F '~' '{if ($1 == $2) {++cnt; print "#"$2};}' \
| sort \
| uniq -c \
| sort -nr \
| cut -f1 -d'#' | head -n10
--8<---------------cut here---------------end--------------->8---
It is easy to produce more stats, for the example the author time
versus the committer time, or the number of newcomers (first commit),
or the hour when committing.
Do not take me wrong, it is not about blaming but it is about health
and how it could be improved. All these numbers show how Guix is
healthy. :-)
Well, all this comment is about "2. Encourage patch review for
committers.". Patch review is about trust, so what could be done to
reduce the workload of "committers"? and smooth everything? Team
and/or delegate? Formalize "maintainer per field" (R, Lisp, Python,
OCaml, maths, etc.)? Obviously without adding too formal stuff. :-)
All the best,
simon
next prev parent reply other threads:[~2020-01-06 21:45 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
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 [this message]
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=CAJ3okZ2M1iMJJUuXJxgdHmvm4zTEMq_KQgwAM_bdWGr+86ha8A@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=38846@debbugs.gnu.org \
--cc=guix-maintainers@gnu.org \
--cc=ludo@gnu.org \
/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).