Listing sub-system maintainers?

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1.1: Type: text/plain, Size: 718 bytes --]

Hello, Guix!

While discussing with a Debian developer at the GHM, it seemed like a
good idea to start developing more “formal” rules now that Guix is
small, in order to scale better in the future.

Sometimes, we’ve seen patches on the list waiting for review for some
time, or people feeling they had not been “formally approved.”
Recently, we’ve had a hard time making a decision and sticking to it
wrt. glibc CVEs.  This is the kind of practical issues that a process
should intend to solve.

I thought a starting point could be to have a list of maintainers,
similar in spirit to the ‘MAINTAINERS’ file in GDB¹.  So I’ve come up
with the attached file, to start the discussion:


[-- Attachment #1.2: MAINTAINERS --]
[-- Type: text/x-org, Size: 4189 bytes --]

This file describes different groups of people who are, together, the
maintainers and developers of the GNU Guix project.

* Overview

  [taken almost verbatim from GDB's ‘MAINTAINERS’ file, with the last
   paragraphs from Guix’s ‘HACKING’ file]

There are four groups of Guix developers, covering the patch development and
review process:

  - The Global Maintainers.

    These are the developers in charge of most daily development.  They
    have wide authority to apply and reject patches, but defer to the
    Responsible Maintainers (see below) within their spheres of
    responsibility.  They have permission to check patches into the
    repository without obtaining approval first.

  - The Responsible Maintainers.

    These are developers who have expertise and interest in a particular
    area of Guix, who are generally available to review patches, and who
    prefer to enforce a single vision within their areas.

  - The Write After Approval Maintainers.

    These are developers who have write access to the Guix source tree.
    They can check in their own changes once a developer with the
    appropriate authority has approved the changes; they can also apply
    the Obvious Fix Rule (below).

Maintainers should always post non-trivial patches to guix-devel@gnu.org.
Trivial patches include fixing typos, fixing obvious mistakes, etc.

Maintainers can commit patches that just add a new package, and a simple one,
if they’re confident (which means they successfully built it in a chroot
setup, and have done a reasonable copyright and license auditing.)  Likewise
for package upgrades, except for upgrades that trigger a lot of rebuilds (for
example, upgrading GnuTLS or GLib.)  There is a mailing list for commit
notifications (guix-commits@gnu.org), so people can notice.

The term “review” is used in this file to describe several kinds of feedback
From a maintainer: approval, rejection, and requests for changes or
clarification with the intention of approving a revised version.  Review is a
privilege and/or responsibility of various positions among the Guix
Maintainers.  Of course, anyone—whether they hold a position but not the
relevant one for a particular patch, or are just following along on the
mailing lists for fun, or anything in between—may suggest changes or ask
questions about a patch!


* Global Maintainers

  Ludovic Courtès
  (+ someone else...)

* Responsible Maintainers

This section lists parts of the Guix source tree their Responsible
Maintainers.

** Core (store, derivations, packages, monads, gexp)

   Ludovic Courtès

** Tools

   Eric Bavier             guix refresh
   Ludovic Courtès         guix package, guix system, guix pull, etc.
   Cyril Roelandt          guix lint
   Mark H. Weaver          guix package

** Build Systems

   Ludovic Courtès          gnu, trivial, perl
   Andreas Enge             gnu, cmake, python
   Cyril Roelandt           python, perl
   Mark H. Weaver           gnu, trivial

** Packages

*** Bootstrap, base, cross-base, make-bootstrap

   Ludovic Courtès
   Mark H. Weaver

*** Specific cross tool chain

   Ludovic Courtès          i686-pc-gnu
   Andreas Enge             mips64el-linux-gnu
   Manolis Ragkousis        i686-pc-gnu
   Mark H. Weaver           mips64el-linux-gnu

*** Architecture-specific

   Ludovic Courtès          x86_64-linux
   Andreas Enge             x86_64-linux, mips64el-linux
   Mark H. Weaver           x86_64-linux, mips64el-linux
   John Darrington          i686-linux

*** Security
    Handling vulnerabilities in Guix and CVEs in packaged software.

   Ludovic Courtès
   Mark H. Weaver

*** GNU Linux-Libre

   Jason Self

*** GNU Hurd

   Manolis Ragkousis

*** Other packages

Everyone!  (Add per-package maintainers?)

*** Packaging guidelines

   Andreas Enge

** User interfaces

   Ludovic Courtès          (guix scripts package), (guix profiles)
   Alex Kost                Emacs, (guix profiles)

** Operating system

  Ludovic Courtès          gnu/system, gnu/services, gnu/build

[-- Attachment #1.3: Type: text/plain, Size: 549 bytes --]


I’ve put names under each item, to get an idea.  We can discuss the
details of who does what if/when we agree on the process; it will be a
voluntary process, of course.

The difficulty is to come up with something useful and not overkill.
The list of “sub-systems” may be too fine-grain, actually.

What do people think of the general idea?  Any suggestions?
Thoughts about simplifications or clarifications?

Thanks,
Ludo’.

¹ https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/MAINTAINERS;hb=HEAD

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]