Subject: Re: GCD005: Regular and efficient releases

From: Steve George <[email-masked]>
Date: Tue, 10 Jun 2025 08:29:13 +0100

Hi Leo,

On Sun, Jun 08, 2025 at 10:25:09PM -0400, Leo Famulari wrote:
> On Fri, May 09, 2025 at 01:53:39PM +0100, Steve George wrote:
(...) 
> Releases have always been a pain point for Guix, at least since I joined
> around 2015.

Thanks for the feedback, it's really useful to have input from a longer time-frame in the project. 

At the end you said:

> 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 kind of agree, and actually I started writing a release plan and then landed up writing a GCD.

The reason I changed path is because I saw a lot of discussions and calls for a release at different times within the project. But we didn't manage as a group to make it happen. For me, that points to us not be aligned as a group and not prioritising releases.

So the purpose of the GCD is that as a group we say "we want to do regular releases" and the impact is that we'll work together to do so: for those that don't want to work on a release the ask is not to do anything that makes creating a release more difficult.

(...) 
> 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

> 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.
(...)

I absolutely agree that we get better at what we practise, so if we release more we can learn and iterate - we'll improve.

It's a great thought experiment of what we would do differently. This is one area where my previous experiences probably doesn't help as I'm a bit "stuck" on the level quality and work that a good release has to have in it. Yeah, it's an interesting question of what a "minimum viable release" would look like from a project and user perspective.

The GCD basically said "reduce complexity by" focusing on:

- fewer packages than the whole archive
- fewer architectures
- fewer release artefacts

I've added a focus on automation in the GCD - your framing is a good way to really think about this.

> 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.
(...)

Yeah, it would be great to have some of that love for the project!

> I'd say you can just start planning the release now, Steve :)

Hah hah hah!

Steve / Futurile