* Listing sub-system maintainers?
@ 2014-09-16 12:49 Ludovic Courtès
2014-09-21 17:06 ` Cyril Roelandt
2014-10-03 20:20 ` Andreas Enge
0 siblings, 2 replies; 4+ messages in thread
From: Ludovic Courtès @ 2014-09-16 12:49 UTC (permalink / raw)
To: Guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Listing sub-system maintainers?
2014-09-16 12:49 Listing sub-system maintainers? Ludovic Courtès
@ 2014-09-21 17:06 ` Cyril Roelandt
2014-09-21 18:50 ` Ludovic Courtès
2014-10-03 20:20 ` Andreas Enge
1 sibling, 1 reply; 4+ messages in thread
From: Cyril Roelandt @ 2014-09-21 17:06 UTC (permalink / raw)
To: guix-devel
On 09/16/2014 02:49 PM, Ludovic Courtès wrote:
> Cyril Roelandt python, perl
How did I end up with Perl? :-p
Cyril.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Listing sub-system maintainers?
2014-09-21 17:06 ` Cyril Roelandt
@ 2014-09-21 18:50 ` Ludovic Courtès
0 siblings, 0 replies; 4+ messages in thread
From: Ludovic Courtès @ 2014-09-21 18:50 UTC (permalink / raw)
To: Cyril Roelandt; +Cc: guix-devel
Cyril Roelandt <tipecaml@gmail.com> skribis:
> On 09/16/2014 02:49 PM, Ludovic Courtès wrote:
>> Cyril Roelandt python, perl
>
> How did I end up with Perl? :-p
Heh, it’s open for discussion. :-)
Ludo’.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Listing sub-system maintainers?
2014-09-16 12:49 Listing sub-system maintainers? Ludovic Courtès
2014-09-21 17:06 ` Cyril Roelandt
@ 2014-10-03 20:20 ` Andreas Enge
1 sibling, 0 replies; 4+ messages in thread
From: Andreas Enge @ 2014-10-03 20:20 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel
There have not been many replies to your message, so I will quickly give
my opinion. The idea looks good to me.
On Tue, Sep 16, 2014 at 02:49:30PM +0200, Ludovic Courtès wrote:
> They have permission to check patches into the
> repository without obtaining approval first.
>
> - 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.
I think we should be less contradictory, and give more freedom to the
maintainers. So I would state that maintainers are allowed to commit
non-controversial patches (which in fact they already do...).
Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-03 20:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-16 12:49 Listing sub-system maintainers? Ludovic Courtès
2014-09-21 17:06 ` Cyril Roelandt
2014-09-21 18:50 ` Ludovic Courtès
2014-10-03 20:20 ` Andreas Enge
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.