Subject: Re: Gathering feedback on GCD005: Guix regular releases

From: Maxim Cournoyer <[email-masked]>
Date: Mon, 23 Jun 2025 12:23:29 +0900

Hi Steve,

Thanks for attempting to tackle the thorny topic of release processes.

I finally took the time to read this carefully and in full.  Here are
some comments, I hope it's not too late!

[...]

> The weaknesses in this release strategy are:

> 1. No clarity on when the next Guix release is.
> 2. Releases are complex and toil for developers.
> 3. Rolling updates aren't suitable for all users.

I'd drop the identified weakness '#3: Rolling updates aren't suitable
for all users' from the GCD; it's not addressed by this GCD, and it's
not clear that being a rolling distribution is a weakness (it's a
strength from the point of view of keeping things simple).

I feel the GCD goes to some lengths emphasizing that releases are a good
thing; while interesting, I think it may be better to take it for
granted and streamline what is already a rather long text, focusing more
on what are the current problems/pain points and what concrete changes
are proposed to address these.  Especially novel changes not already
captured in the 'release' Make target of the project would be important
to highlight/capture.

For example, some rudimentary package sets and architecture subsets are
already used; packages via /etc/manifests/release.scm, and architectures
via the SUPPORTED_SYSTEMS and GUIX_SYSTEM_INSTALLER_SYSTEMS Make
variables.

This target gives a good idea of what is in scope for the release, in
terms of release artifacts.  I've brushed that topic in the past [0],
but let's revisit this with more details here, for the benefit of this
GCD:

- Source distribution to be uploaded to the GNU FTP server

- Binary package of Guix for installation via guix-install.sh
  (currently: x86_64-linux i686-linux armhf-linux aarch64-linux 
  powerpc64le-linux riscv64-linux)
  
- Updated Guix package (which means its test suite must pass)

- ISO installation images for the supported systems (currently:
  x86_64-linux, i686-linux)
  
- VM image for the supported systems (currently: x86-64)

So that gives a rough initial scope for making a release.  It means
that:

1. Guix and all its dependencies must build successfully on multiple
architectures.
2. Xfce-desktop closure must be buildable on x86-64

Just this can take a lot of time, as Guix itself has to be built twice
even on slower machines like aarch64-linux. That's because we want the
referenced Guix package in the installation image to be the one being
released.

Then comes the *manual* testing/validation of these, which can takes time:

1. Installing the binary package via guix-install.sh in a VM, ideally
multiple different foreign distributions and see that it works
correctly.

2. Running the qcow2 image with something like virt-manager or
GNOME-Boxes; ensuring the system works correctly, with SPICE niceties
like copy-paste and dynamic display resizing.

3. Installation from scratch in a VM using the bootable ISO.  At least
the default settings should work, and it's nice to test more, of course.

Finally comes the step of uploading/communicating the changes:

1. Update NEWS file.  There's a update-NEWS Make target that does some
automation, but a lot of time will be sunk into manually combing
thousands of commits for interesting changes to mention in the NEWS file
(it's the part I dislike most) -- a better process would ensure NEWS are
captured/updated at the time changes are committed (burden on the
committer, not the release person).

2. Draft a blog post for the release. Traditionally highlighting
interesting changes, with examples and all.  This takes some time
too/writing skills.  In my opinion, if the goal is to automate releases,
this should be stripped down to the essentials, with a more interesting
blog posts following if we have people interested in authoring them.

3. Upload the release artifacts, using the gnupload to the GNU FTP and
email a few mailing lists, as mentioned in the doc/release.org file.

[0]  https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00177.html

Oof, sorry for the wall of text.  Back to the actual GCD document being
discussed:

> Guix is both a package manager that can be hosted on other Linux
> distributions, and a Linux distribution. Limiting the range of
> packages and services that receive attention is consequently more
> complicated. Guix already has manifests to track which packages are
> used by Guix System's installer , so this proposal extends that
> concept.

I'd replace the term 'Linux' with GNU/Linux.  This is a GNU package,
let's not miss an opportunity to advertise GNU's existence/significance
:-).

I don't think we should introduce finer-grained package sets that must
be discussed for each release.  That goes against automation and
enlarges the current scope, which we're already struggling with.  If the
release artifacts build and test fine (which include a lightweight
desktop image), we should be minimally good to go.

> and removing the broken package from the archive using the Deprecation
> Policy. As always, packages may be un-deprecated and returned to the
> archive at a later date.

s/removing/deprecating/

> The aim in this template is for a 12 week active release project,

That's a lot of time!  I dream of a CI workflow that would build the
release artifacts and tests them minimally: when green, releasing would
take a couple days at most.

I think the process should only impact the operations of the release
team: that means not forcing everyone on a freeze, or a different
branch, etc.  The release team can simply branch from master to a
release branch and refine it there.  When it's done and released, it can
be merged back into master.  While trying to have teams synchronized for
a release sounds good, I think in practice this will cause problems.  So
releasing should be orthogonal to the status/milestones of teams, in my
opinion.  Releasing often will make that less of a problem anyway.

From the Appendix 1: release project template, I'd drop or edit these:

s/Notify teams/Notify contributors (e.g. guix-devel)/

I'd drop: 'Package set finalisation' (release artifacts is what
matters), 'Toolchain and transition freeze' (orthogonal),
'Major updates freeze' (shouldn't be much of an issue, with topic
branches being QA'd), 'Breaking changes to next-master' (changing main
flow is unnecessary), 'Ungraft
master branch' (should be done continuously / it's orthogonal).

In the past we've paid attention to having fresh translations in for a
release; I don't see this covered here.  Perhaps it's OK to be left as
an orthogonal topic if we release often enough.

So these are my thoughts, which I'm afraid are not too well
ordered/presented, but I've already spent more than 1 h writing this
email so I'll let it go :-).

Again, I think this is a fine text (it's very well written), and I
appreciate your initiative.  I think it's important to try to simplify
things rather than complicate them though, which this GCD in its current
form does to some degree (by codifying a larger scope than needed, in my
opinion).

I hope that's useful!

-- 
Thanks,
Maxim