Subject: Re: GCD005: Regular and efficient releases

From: Leo Famulari <[email-masked]>
Date: Sun, 8 Jun 2025 22:25:09 -0400

On Fri, May 09, 2025 at 01:53:39PM +0100, Steve George wrote:
> Below you'll find a proposal for moving to a regular release cycle.

First, my sincere thanks to you for making the effort to analyze the
situation, make a proposal, and shepherd the discussion.

Releases have always been a pain point for Guix, at least since I joined
around 2015. Of course, they seemed to get much harder as the codebase
and our ambitions grew. Now we have a binary for the package manager,
the source tarball, VMs, an installer image, desktops that we aim to
support, a variety of CPU types, two operating systems (Linux and Hurd),
etc. It's a huge amount of work on top of the Guix-specific difficulties
--- functional package management is tricky here --- that relate to
making a release.

In the past, we were able to freeze for a week here and there, but the
Guix project was much smaller and able to coordinate as a group, with
only a few committers, so it wasn't as hard to imagine a freeze as it is
now. We'd freeze for a few days and extend to a week when we had
trouble. Maybe it sounds crazy to freeze for 9 weeks, but compare us to
Debian or Linux. It's not necessary to deploy updates every minute of
the day. Git is decentralized and we all know how to use it.

Compare Guix releases to what's happened for TLS and web security since
Let's Encrypt automated the issuance and renewal of X.509 certificates.
That went from a manual, infrequent, expensive, and error-prone process
to something that is easy, automatic, and basically required for a web
site. TLS is everywhere now. Part of that process was a drastic
reduction in scope of what SSL / TLS meant. It used to be that an SSL
connection told you something about the people behind the web site. Only
trustworthy and capable organizations used SSL (banks, etc).  There were
tiers of certificates that somehow vouched for the web site. I'm not
sure if younger people realize the depth of that change. Let's Encrypt
said, "No, the certificate only means that the person that controls the
DNS name is serving you the data - nothing else. The connection is
confidential and authentic". It's purely a cryptographic construct now,
and TLS is ubiquitous. Nobody's bank account is getting hacked by a
rogue wifi network anymore.

BIG POINT:

Similarly, I recommend we make releases more automatic and more frequent
by reducing their scope. Until our capabilities grow to the point that
we can actually regularly create a bunch of release artifacts that have
been well tested for a bunch of platforms, let's figure out how to make
the minimum viable release from which users can install Guix and then
instantiate whatever it is they need.

We'd need to be creative here, from a technical point of view. I don't
know what this minimal release artifact is.

All the different CPU platforms, the Hurd, the desktops, the VMs...
people need to step up. The release team should not be validating that
stuff. The release needs to install a working Guix on Debian and Fedora.
Needs to install a bootable console on x86_64-linux (no, let's not ask
users to run `guix system init`). And maybe aarch64. But I wish we had
statistics of substitute downloads, to understand what people are
actually using. We should be bold.

People love releases. Releases are an occasion to celebrate. People make
t-shirts, stickers, have a drink on IRC, in Brussels, Bordeaux, and
Paris, and hopefully other places (any New Yorkers reading this???).
This kind of hoopla can entice people to join our project, and in the
long run we may gain the capability to do big complicated releases with
a bunch of artifacts again.

Also, our old releases work until they don't. We want SWH to save us
from bitrot, but our packages keep fighting us with little time bombs
that break the build after certain dates. We need releases to keep Guix
buildable for new installations. Guix is a build-from-source distro,
although we hide that well.

Personally I'm not sure we need a GCD here. The same leadership required
to issue a release is needed to land a controversial and disruptive
change. And making releases is not controversial or significantly
disruptive. I'd say you can just start planning the release now, Steve :)

Leo