Re: On the quest for a new release model

[Maxim Cournoyer]

Hi,

Greg Hogan <code@greghogan.com> writes:

> On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès <ludo@gnu.org> wrote:
>> 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.
>
> So a release team like every other team? An etc/teams.scm team (as
> opposed to a mailing list team) also promotes the notion that much of
> the needed work is outside of the release process. There were several
> ideas for improvement earlier in this thread, but for another I
> noticed that NixOS provides AMIs. If someone was to create the
> necessary scripts and documentation for publishing Guix release AMIs
> it would be handy to have a team to guide that contribution.

It could be an etc/teams.scm team, although these have so far always
existed with a scope of files, that works in conjunction with 'git
send-email' to notify people of modified files.  I don't have anything
against the idea though; they'd at least serve as a record of who to
contact for some scope of responsibility.

>> 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.
>
> Looking through doc/release.org, much of the work should be the
> responsibility of other teams. NEWS could be updated when team
> branches are merged.

That's a low hanging fruit that would greatly help picking to ease the
work of producing a new release: some new contributing guidance that
would mention new significant features should have an entry written in
both the NEWS file and etc/news.scm.

-- 
Thanks,
Maxim