guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On maintaining GNU Guix


From: Ricardo Wurmus
Subject: Re: On maintaining GNU Guix
Date: Thu, 11 Jul 2019 11:01:11 +0200
User-agent: mu4e 1.2.0; emacs 26.2

Christopher Lemmer Webber <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]