Re: On the quest for a new release model

[Greg Hogan <code@greghogan.com>]

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.

> 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. "Identifying and addressing bugs considered
release blockers" and "Stabilizing things" are an ever-present issue.
Time-based releases (whether calendar or hybrid versioning) can
coordinate project stability (as with the past unscheduled freezing of
the master branch).

Greg