Re: On the quest for a new release model

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Efraim Flashner <efraim@flashner.co.il> writes:
>
>> On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote:
>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>
>>> > Efraim Flashner <efraim@flashner.co.il> writes:
>>> >
>>> >> Since, IMO, the major uses of the actual guix package is for the daemon
>>> >> and the installer, I think we could tag a minor release just about every
>>> >> time we bump the guix package.
>>>
>>> That's a sensible approach.  How should the discussion proceed further?
>>> Do we have a proxy to determine whether everyone who needs to be
>>> involved for consensus-based decision-making has weighed in?
>>
>> I'd argue that cutting releases is one of those specifically maintainer
>> duties but I'd love to hear from other people who disagree.
>
> I'd tend to agree.  A maintainer who doesn't cut releases or organize to
> make them happen is a poor maintainer (hello!).

Heheh.  :-)

As has been discussed multiple times at the Guix Days and on this list
(I think?), I believe what we need is a release team with rotating
duties.  That is, a bunch of 3–5 people commit to doing the work leading
to 1.5.0; then a new team (possibly with overlap) takes over for the
next version, and so on.

This is what NixOS has been doing for some time, for example, and it has
several advantages: it distributes responsibilities and power, and it
ensure everything is properly documented so people can actually carry
out the task.


As mentioned previously, I’m happy to mentor and help whoever steps up.
I know there are people up to the task; at least one person on the team
needs to have commit access, but apart from that, don’t be shy!

Our first exercise will be to make a “fake” release as a way to test
documentation and find out about missing bits and corner cases.

Ludo’.