Subject: Re: GCD005: Regular and efficient releases (submitted)

From: Liam Hupfer <[email-masked]>
Date: Thu, 05 Jun 2025 23:41:22 -0500

Hi Steve, Guix,

First, thanks for moving the discussion forward here! Release discipline
is one of the marks differentiating a toy project and a serious one.

I am not a regular contributor yet but am an active user and list lurker
and have some impressions of current pain points. I also hang around
Nixpkgs and contribute there (mainly helping with the Guix package and
services) so I have some familiarity with their processes.

I tend to agree with Andrew’s feedback
(<https://yhetil.org/guix-patches/[email-masked]>) and others; we
need to be very judicious about imposing processes in this GCD that the
volunteer community can’t properly support yet. As discussed, while
regular releases are a useful marketing tool, we have to avoid giving
the impression that users should stay on releases. For the foreseeable
future stable branches are out of scope, so these releases only exist to
provide a base for new installations and a rollback target of last
resort. Good to see the revisions moving in this direction.

I agree with others’ feedback that we should be conservative with the
scope at first to avoid imposing on general progress. We should limit
ourselves to only what is necessary for foreign distros to ship Guix and
a base Guix System installer.

The GCD doesn’t discuss tagging conventions but it came up in
discussion. Even if we move to a strict time-based schedule as is
proposed, I am a bit concerned about calver since it gives users the
impression of stable branches based on how other distros (NixOS, Ubuntu)
use calver. Sticking with semver until we can support stable branches
feels worth considering.

I do like the “when it is ready” model Vagrant mentions from Debian.
Once we agree to start the release process, readiness of a minimum
viable package set can dictate the time to release. I’m not opposed to
the landing zones you wrote down but I also don’t think they’re
necessary to make explicit. If a bug considered release blocking exists,
the release will be postponed until it is fixed (a tautology, I guess).
Nothing wrong with having a planned schedule but it can be kept simple
and we can note that it’s not a guarantee.

> The package sets would be:
>
> * minimal: packages required to boot and install a minimal Guix or Guix System
> install.  This would include the guix daemon, kernels, boot loaders,
> file-systems and minimal utilities.
> * standard: packages that create a core installation for all other uses.
> * desktop: provides the packages necessary for a desktop.  This would include
> the smallest set required for the initial environment.

Is standard necessary? What’s the difference between minimal and
standard? These proposed sets seems to overlap with the teams concept
somewhat. Either the package is release-critical or it isn’t, and there
seems to be consensus that a functioning initial installation with a
graphical DE is critical. Can we simply define one “release set”?
Actually, based on the freezes you discuss later, maybe one “build set”
for toolchains and Guix, etc, and one “release set” encompassing the
build set as well as the (closure of) critical top level applications
like editors and DEs?

>   - Coverage: all packages and services that are not explicitly platform
>     specific must work to be included in the archive.

So any package or service in the entire repository that doesn’t build on
a primary arch must be removed before the release? Based on how Nixpkgs
ZHF goes I’m not sure this is realistic. Do you mean packages and
services in the release set? There are a lot of random leaf packages
that aren’t release critical but can become unmaintained as time passes.
As more services are added this is likely to become the case there too.
I’m not sure the release team should be burdened with hunting all these
down. A time-based best-effort cleanup period like ZHF every release is
certainly valuable, though.

>   - Package status: package updates should build for this architecture.  If a
>     package update is broken it must not be pushed to users (e.g. master).
>   - Security: all packages that are maintained upstream receive updates

These points don’t seem related to releases but rather general policies
about master? I guess you are defining the architecture tier concept
here but this was confusing to me at first in the context of reading the
GCD as a whole.

> # Appendix 1: Release Project Template

I know the appendix is just an example (“non-normative” in spec
parlance) but I feel like it warrants review if it’s going into the GCD
as reference material. We should keep it concise and can get more
elaborate when planning the first release after the GCD is approved.

I do not think the major updates freeze and hard freeze are both
necessary. I think given the discussion on limiting the scope of a
release effort, we don’t need to bother with freezing all major updates
in week 8 for all packages, just the ones in the closure of the release
set. If particular maintainers want to keep shipping R or Haskell or
Emacs package ecosystem updates during the release we should let them
IMO, trying to approach a pristine full package set is not feasible yet
and we don’t want to encourage people to stay on tags anyway. An
informal cleanup period seems fine but a formal global freeze seems to
impose too much on niche package ecosystems maintained by volunteers
that ultimately won’t affect the release artifacts.

> | -5 | Nominate a release team |
> | -4 | Notify teams of upcoming release |
> | 01 | Release project start |

The use of negative indices gets confusing when the start is week 1. Is
there a week 0 or not? IMO the NixOS example where release week is 0 is
intuitive. Countdown to release!

> ### Toolchain and transition freeze (week 04)
> No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes
> (e.g. java).  There should be no changes that will cause major transitions.

> Debian defines a transition as one where a change in one package causes
> changes in another, the most common being a library. This isn’t suitable for
> Guix since any change in an input causes a change in another package.
> Nonetheless, any change that alters a significant number of packages should be
> carefully considered and updates that cause other packages to break should be
> rejected.

If Debian defines the term “transition” in a way that makes it
meaningless for Guix, we shouldn’t reuse it. I don’t find it a very
intuitive term anyway. Maybe “mass rebuild”? I know I’ve seen that term
before in Guix contexts. Regardless, I don’t think restricting mass
rebuilds for 8 weeks is viable. If we focus on the release set as is
being discussed I don’t think we need to care about mass Haskell or R or
Emacs rebuilds.

> This concept comes from the Nix project where they flow big changes into a
> staging branch while they do release stabilisation to prevent big flows of
> breaking changes into master which broke one of their releases [^6].

The proposed branching model is not that similar to Nixpkgs, I think. In
Nixpkgs they don’t bother with a next-master because master is only
restricted for ~3 weeks.

While merges to and from the Nixpkgs staging branch are affected by the
release process, the branch itself is not really tied to release
stabilization. It is for grouping mass rebuilds and is used outside of
release time too. I think we should drop the reference since next-master
as it is proposed here is not really related to the Nixpkgs staging
branch.

IMO we should drop the discussion of this next-master integration branch
from the GCD and revisit it if it seems necessary during a release. In
the context of the proposal to not freeze non-release critical package
ecosystems it makes sense to me, anyway.

> * release branch: regularly merged from master, tracks the release artifacts.
> * master branch: receives security and resolutions of RC bugs.
> * next-master: everything that normally goes to master.

Why is the release branch created while master is still frozen for 3
weeks?

Sorry for the scattered email. Hopefully you find some of it valuable.
Thanks again for your work on this!

—Liam

PS: I took a look at the release manifest you mentioned and was
surprised to see how many options the installer proposes in
%system-packages. IMO we should feel empowered to drop quite a few of
those when preparing a release. Emacs, Vim, and Nano should be in the
release set but not EXWM, Ratpoison or Awesome. Anyone who wants to
install a WM can expected to have their first Guix system generation be
VT only or a more mainstream DE (or guix pull from a foreign distro and
build their own installer if desired). WMs can certainly be added to the
installer if interested parties choose to test them during the release
cycle but should not block the release once the release set is ready
(Bash, OpenSSH, GNOME, wpa-supplicant, etc). We can remove any broken
options from the installer before tagging. Ideally we should have
VM-based automated testing of any DEs offered in the installer as well.

PPS: Another release-related issue that isn’t discussed is backporting
critical patches. We didn’t backport patches for CVEs and tag 1.4.x
releases; distro maintainers had to apply them from blog posts. The blog
posts were helpful but that’s not how bug fixes should be shipped! I
help out with the Nix package and we’re carrying five patches now, four
of which are for CVEs. Maybe this is to prevent divergence where guix
pull thinks you are downgrading but we should look into how to handle
that better. Maybe patch releases can ship with the SHA for the latest
commit on master containing equivalent security patches embedded
somewhere in the Guix modules so ‘guix pull’ can treat that as the point
of comparison for downgrade warnings instead of the tag commit itself?