unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Guix Devel <guix-devel@gnu.org>
Cc: GNU Guix maintainers <guix-maintainers@gnu.org>
Subject: On commit access, patch review, and remaining healthy
Date: Thu, 02 Jun 2022 17:10:43 +0200	[thread overview]
Message-ID: <87ee07m77w.fsf@gnu.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

Hello Guix!

Following on the theme of patch review, I did some stats with the
attached tools on commits since 1.3.0:

  • 20,489 commits were made since then;

  • 4,476 were commits pushed on behalf of a non-committer;

  • of these, half were pushed by 2 committers, out of 40ish.

Some conclusions we can draw:

  • We have a strong core development team, which I think is great
    compared to many free software projects.

    Perhaps the flip side of this is that we make too little space to
    newcomers.  (I feel we’re almost the opposite of a typical
    Git{Hub,Lab}-hosted project where drive-by contributions are common
    and long-term commitment is rare.)

  • Review work is severely lacking.  The manual reads (info "(guix)
    Commit Access"):

      […] the project keeps moving forward because committers not only push
      their own awesome changes, but also offer some of their time
      _reviewing_ and pushing other people’s changes.  As a committer,
      you’re welcome to use your expertise and commit rights to help
      other contributors, too!

    Yet, most committers don’t allocate time to review and push other
    people’s changes.

    Why aren’t we, committers, not doing more review/apply work?  Is it
    too intimidating?  Would having a documented review checklist help?

    If you’re not using Emacs, what actionable steps should we take with
    mumi and other tools to help you (Arun made several proposals in
    their Guix Days talk)?  If you are using Emacs, does debbugs.el have
    shortcomings that make it a problem to review patches?

  • We need to be able to renew committers.  There’s a process in place
    to remove, at least temporarily, committers that have been inactive
    for a year or more, and I think it’s good (info "(guix) Commit
    Access").

    Maybe we should also encourage committers who have “moved on” to let
    the project know so we have a clearer picture of who’s in—meaning
    available not just to commit their own occasional patches, but also
    to help other contributors.

    In addition to that, we need to encourage contributors who are not
    committers yet, which obviously means reviewing and applying their
    contributions in a timely fashion.  We need to grow prolific
    contributors into leadership positions to they can become committers
    and take part into this whole process.

In short, we need to break out of a potentially vicious circle where
active members don’t make the work that would allow newcomers to get
more involved, at the risk of burning out themselves.

Let’s make sure this project keeps striving for decades to come!  :-)

Thoughts?

Ludo’.


[-- Attachment #2: the code --]
[-- Type: text/plain, Size: 2692 bytes --]

(use-modules (git)
             (git repository)
             (git reference)
             (git oid)
             (git tag)
             (git commit)
             (git structs)                        ;signature-email, etc.
             (guix git)
             (srfi srfi-1)
             (srfi srfi-26)
             (ice-9 match)
             (ice-9 vlist))

(define commit-author*
  (compose signature-name commit-author))
(define commit-committer*
  (compose signature-name commit-committer))

(define-syntax-rule (false-if-git-error exp)
  (catch 'git-error
    (lambda () exp)
    (const #f)))

(define* (fold-commits proc seed repo
                       #:key
                       (start (reference-target
                               (repository-head repo)))
                       end)
  "Call PROC on each commit of REPO, starting at START (an OID), and until
END if specified."
  (let loop ((commit (commit-lookup repo start))
             (result seed))
    (let ((parent (false-if-git-error (commit-parent commit))))
      (if parent
          (if (and end (oid=? (commit-id parent) end))
              (proc parent result)
              (loop parent (proc parent result)))
          result))))

(define (reviewers repo commits)
  "Return a list of review count/committer pairs."
  (define vhash
    (fold (lambda (commit result)
            (if (string=? (commit-author* commit)
                          (commit-committer* commit))
                result
                (vhash-cons (commit-committer* commit) #t
                            result)))
          vlist-null
          commits))

  (define committers
    (delete-duplicates
     (fold-commits (lambda (commit result)
                     (cons (commit-committer* commit)
                           result))
                   '()
                   repo)))

  (map (lambda (committer)
         (cons (vhash-fold* (lambda (_ count)
                              (+ 1 count))
                            0
                            committer
                            vhash)
               committer))
       committers))

(define (reviewer< r1 r2)
  (match r1
    ((count1 . name1)
     (match r2
       ((count2 . name2)
        (< count1 count2))))))

(define repo
  (repository-open "."))

(define commits
  (commit-difference (commit-lookup repo
                                    (reference-target (repository-head repo)))
                     (commit-lookup
                      repo
                      (tag-target-id
                       (tag-lookup
                        repo
                        (reference-target
                         (reference-lookup repo "refs/tags/v1.3.0")))))))

             reply	other threads:[~2022-06-02 15:13 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 15:10 Ludovic Courtès [this message]
2022-06-02 20:22 ` On commit access, patch review, and remaining healthy Brian Cully via Development of GNU Guix and the GNU System distribution.
2022-06-03 19:37   ` Ludovic Courtès
2022-06-03 21:17     ` Ricardo Wurmus
2022-06-07  7:08     ` Efraim Flashner
2022-06-07 15:11       ` Ludovic Courtès
2022-06-08 11:39         ` Efraim Flashner
2022-06-08 21:10           ` Ludovic Courtès
2022-06-20 12:53         ` Hartmut Goebel
2022-06-21 15:44           ` zimoun
2022-06-22  9:19             ` Munyoki Kilyungi
2022-06-02 20:32 ` Pier-Hugues Pellerin
2022-06-03 19:42   ` Ludovic Courtès
2022-06-02 21:35 ` Luis Felipe
2022-06-03  8:22   ` Feed on specific topic (public-inbox?) zimoun
2022-06-03 10:51     ` zimoun
2022-06-06 12:11 ` On commit access, patch review, and remaining healthy Arun Isaac
2022-06-06 21:43   ` Ludovic Courtès
2022-06-07  6:44     ` zimoun
2022-06-08  9:30       ` Giovanni Biscuolo
2022-06-14 12:24         ` zimoun
2022-06-15  7:01           ` Arun Isaac
2022-06-15  9:19             ` Ludovic Courtès
2022-06-19  6:55             ` Paul Jewell
2022-06-20 12:11               ` Arun Isaac
2022-06-15 15:11           ` Giovanni Biscuolo
2022-06-08 10:54     ` Giovanni Biscuolo
2022-06-09 19:55     ` Arun Isaac
2022-06-08  9:49   ` Giovanni Biscuolo
2022-06-09 19:50     ` Arun Isaac
2022-06-10 12:27       ` Giovanni Biscuolo
2022-06-10 15:03         ` Efraim Flashner
2022-06-10 16:10           ` Giovanni Biscuolo
2022-06-10 16:26           ` Giovanni Biscuolo
2022-06-10 15:03         ` Maxime Devos
2022-06-11  4:13         ` Thiago Jung Bauermann
2022-06-11  9:37           ` Ludovic Courtès
2022-06-14 11:54           ` zimoun
2022-06-14 15:54             ` Maxim Cournoyer
2022-06-15  6:46               ` Arun Isaac
2022-06-13 12:19         ` Arun Isaac
     [not found] <mailman.12124.1654864076.1231.guix-devel@gnu.org>
2022-06-12  8:18 ` Ricardo Wurmus
2022-06-12  9:42   ` Giovanni Biscuolo
2022-06-12 13:10     ` Maxime Devos
2022-06-13  9:34       ` Giovanni Biscuolo
2022-06-13 10:48         ` Maxime Devos
2022-06-13 14:21           ` Giovanni Biscuolo
2022-06-12  8:21 ` Ricardo Wurmus

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=87ee07m77w.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@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).