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

From: Steve George <[email-masked]>
Date: Mon, 23 Jun 2025 15:14:11 +0100

Hi Maxim,

On Mon, Jun 23, 2025 at 12:23:29PM +0900, Maxim Cournoyer wrote:
(...)
> 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 :-).
(...)

Thanks for going through the proposal in detail.

The section where you set out all the detailed steps will be particularly useful for revising our release documentation.

I got three things from your email:

(a) concern about the impact on contributors of releases
(b) concern over increasing the scope of releases
(c) desire to focus on the concrete elements with less intro/context

You said:
> 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.

I wonder if we're all aligned that releases are important, and if we're willing to make trade-offs to achieve them. Consequently, intro text is important to lay out the context of why releases matter, creates a goal ("annual releases") and asks the group if they're willing to prioritise having them.

I would like to excite and rally all our contributors around doing regular releases. I would like us to emphasise release much *more* to contributors. So we have a shared group goal, with acceptance of it as a priority and the responsibilities that entails.

What is the impact on contributors?

We are all motivated by different things, and we're all volunteers. So to be totally clear I'm not saying _everyone_ has to practively take part in releases. But, this GCD does try to get alignment that releases are important, all contributors should be aware one is happening - and the _minimum impact_  is that contributors should not do things that are likely to prevent a release.

You bring up how much committers could be interrupted by releases:

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

At a practical level, in my experience the main reason why a distribution fails to hit it's release date is that another developer/team breaks the release by integrating some massive change that then invalidates all the QA. For a rolling release this specifically means making sure that the output of the initial install and then first user-experience of 'guix pull' works. 

I absolutely agree it should be as short as possible. I've added the following to the freeze step:

Each Release Team will iterate and improve the release process, so it's possible that this
freeze period will be reduced, changed, or removed over successive releases.

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

On package sets I've learnt more about how it works and they've been reduced. The updated version of the `package sets` is in-line with my understanding of what you have in your email and what Efraim and Ludo have told me. It formalises what the project has, but doesn't expand the scope.

It now says that the release team MUST QA the default installer options, using the primary architectures (x86/AArch64) on the three installation methods which you listed as:

> - Binary package of Guix for installation via guix-install.sh
> - ISO installation images for the supported systems
> - VM image for the supported systems (currently: x86-64)

Also added that there's a source release that downstream GNU/Linux distributions can use:

> - Updated Guix package (which means its test suite must pass)

Fixing terminology:
(...)
> 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
> :-).
(...)

Thank-you.

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

Agreed.

This seems like a topic that we should discuss as a group. Everyone wants something, but it seems we're not sure how to get started.

> Again, I think this is a fine text (it's very well written), and I
> appreciate your initiative.

Thank-you!

Steve / Futurile