On maintaining GNU Guix

On maintaining GNU Guix

[Ricardo Wurmus]

Hello there,

almost three years ago, Ludovic asked me to become co-maintainer of GNU
Guix.  Every GNU package has at least one maintainer, whose role is to
represent the project in communications with the larger GNU project and
to keep an overview on planned activities, and to effectively guide the
project by fostering consensus within the developer community.

Over the past three years it has become evident that increasing the
number of maintainers was a good idea, especially for a project growing
as quickly as Guix.  For some time now both Ludovic and I have been in
agreement that we could do this again and extend the co-maintainership
to a *collective* of maintainers.

This would allow each of the maintainers to better concentrate on
selected sub-projects, and to increase the likelihood of having an
active co-maintainer around when other co-maintainers are unavailable.
We also hope that this change will decrease the importance of any
individual maintainer’s presence and attention, and eventually lead to a
more collective and perhaps representative way of arriving at decisions
and breaking ties when necessary.

The Guix project is very lucky to have attracted many people who have
contributed for years, who have repeatedly demonstrated the skills that
are desired in co-maintainers, and who share our vision for Guix as a
means to make the theoretical freedoms of free software a *practical*
reality for users of the GNU system.

If you already have commit rights, that’s because we trust your
expertise on parts of the code as well as your ability to further the
project goals, so we encourage you to consider joining the
co-maintainers collective.  If you do not have commit rights but you’ve
been following along and are familiar with the project, you might want
to consider joining as well!

You are welcome to write email to guix-maintainers@gnu.org to indicate
your interest and to request details.

--
Ricardo

Re: On maintaining GNU Guix

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> This would allow each of the maintainers to better concentrate on
> selected sub-projects, and to increase the likelihood of having an
> active co-maintainer around when other co-maintainers are unavailable.
> We also hope that this change will decrease the importance of any
> individual maintainer’s presence and attention, and eventually lead to a
> more collective and perhaps representative way of arriving at decisions
> and breaking ties when necessary.

+1!

In addition... I think we aren't at the point where it's applicable, but
in considering the point where Guix's community grows big enough where
many people contributing to the main repository is untenable, I think a
move to something like what the Linux kernel does (different people
responsible for certain trees) might make sense.

I don't think we're there yet though.

Re: On maintaining GNU Guix

[Ricardo Wurmus]

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Ricardo Wurmus writes:
>
>> This would allow each of the maintainers to better concentrate on
>> selected sub-projects, and to increase the likelihood of having an
>> active co-maintainer around when other co-maintainers are unavailable.
>> We also hope that this change will decrease the importance of any
>> individual maintainer’s presence and attention, and eventually lead to a
>> more collective and perhaps representative way of arriving at decisions
>> and breaking ties when necessary.
>
> +1!
>
> In addition... I think we aren't at the point where it's applicable, but
> in considering the point where Guix's community grows big enough where
> many people contributing to the main repository is untenable, I think a
> move to something like what the Linux kernel does (different people
> responsible for certain trees) might make sense.

We already have many largely independent modules that people work on in
an independent fashion.  There are champions for packages written in
certain languages (Java, Rust, Go, R, Haskell, etc) and in some tangible
sense the quality of packages in those modules is ensured by those
people.

If it would help we could make this sort of module maintainership a
official (an idea brought forward by janneke some months ago) by
recording it somewhere or by automating requests for review when patches
come in (an idea fielded by Andy Wingo).

I don’t think we need separate repositories for Guix packages just yet,
but even for the separate repositories that we do have (website, videos,
maintenance, etc) we also generally have “project managers” or “Meister”
who are more familiar with them and can be considered authorities in
those areas.

--
Ricardo

Re: On maintaining GNU Guix

[Marius Bakke]

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

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Ricardo Wurmus writes:
>
>> This would allow each of the maintainers to better concentrate on
>> selected sub-projects, and to increase the likelihood of having an
>> active co-maintainer around when other co-maintainers are unavailable.
>> We also hope that this change will decrease the importance of any
>> individual maintainer’s presence and attention, and eventually lead to a
>> more collective and perhaps representative way of arriving at decisions
>> and breaking ties when necessary.
>
> +1!
>
> In addition... I think we aren't at the point where it's applicable, but
> in considering the point where Guix's community grows big enough where
> many people contributing to the main repository is untenable, I think a
> move to something like what the Linux kernel does (different people
> responsible for certain trees) might make sense.

There are aspects of this workflow that we can adopt today that I
believe would make things easier for contributors.  Specifically, I
think many people would be more comfortable changing the "guts" of Guix
if they could push 'nckx/staging' or 'rhelling/core-updates' knowing
that it would get pulled eventually, without having to know intimate
details about the state of the build farm or bug tracker.

Besides, I've always wanted to do an octopus merge...  ;-)

PS: I am really happy that Rutger has been taking care of Mesa lately.
I hope more people will step up to watch after packages they care about.

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