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

From: Ludovic Courtès <[email-masked]>
Date: Wed, 11 Jun 2025 22:58:44 +0200

Hi Steve,

Steve George <[email-masked]> writes:

>> Perhaps I overlooked it, but it’s not clear to me how package sets
>> affect the release process.
>> 
>> I would expect things like “package set X must successfully build on all
>> Primary Architectures at time of release”, “package set Y is provided on
>> a best-effort basis”, or things along these lines.
>
> Maybe it's a bit too diffuse in what is a long document, it says:
>
> "Packages within the `package sets` must build on the primary
> architectures (see definition lower).  As part of the release's QA
> contributors would be asked to these these packages."

Right.  I guess my question is more: why do we define 5 package sets if
in the end the same requirements apply to all of them?

My thought, mostly encoded in ‘etc/manifests/release.scm’, is that we
can probably have two package sets with slightly different requirements.

BTW, there’s one thing the document doesn’t mentioned but which is/was
captured by ‘release.scm’, and that’s cross-compilation.  There’s a
small selection of packages that we want to be able to cross-compile
from x86_64-linux to a small selection of target triplets (i586-pc-gnu,
aarch64-linux-gnu, etc.).  But… maybe we can leave it out of the GCD?

> The main goal is to focus attention during testing, particularly as
> there's always some level of manual testing by a Release
> Team. Efraim's version still has the %system-packages, and what I
> would propose is to tighen it up further:
>
> - %system_packages (what I called minimal): requirements for the installer including a default graphical desktop.
> - %desktop_packages (what I called desktop): additional graphical desktops, other options like NTP and Tor. 
>
> The Release Team would focus testing on the things on the installer's
> critical path. In Efraim's version there's actually three sets -
> %bootloader_packages, %filesystem_packages and
> %system_packages. Anyway, these all MUST work because they align with
> the installers defaults. Failures in these packages are release
> critical bugs.
>
> Practically this means testing the end-to-end install process of Guix
> System with these defaults on (a) primary architectures (x86 and
> AArch64), also through KVM (QCow2 image), and tested on the major
> foreign distribution's (e.g. Debian, Fedora, Ubuntu).

OK.

> Non-default packages that are in the installer (but not a default
> option) go into (a new) %desktop_packages. These get the next layer of
> testing, these SHOULD work as we shouldn't ship something we know is
> broken, but it's less critical. We're assuming that each Team is
> shipping things that work, and it's 'reasonable efforts' for the
> Release Team to try and check that the installer works for them.
>
> This focuses attention by reducing the scope that the release team "must" test.
>
> I also proposed a "minimal" group which would be "packages required to
> boot and install a minimal Guix or Guix System". Is it the same idea
> as %base_packages?

I think so.

> I'm wondering if we should separate "Guix installed as a packge
> manager" into it's own package set. In the long run this would be a
> building lock that allow us to align with Philip's suggestion of
> following a more Nix-packages / Nix OS separation of releases. What do
> you think?

The NixOS/Nixpkgs distinction doesn’t really exist anymore (it used to
be two separate repos but the two are necessarily tightly coupled), so
I’m not sure what the suggestion is.

>> > ## Release artifacts
>> > 
>> > Using the primary architecture tier and the package sets would involve creating
>> > the following release artifacts:
>> > 
>> > - GNU Guix System ISO image
>> > - GNU Guix System QCOW2 image
>> > - GNU Guix installer
>> 
>> This omits two important things:
>> 
>>   • The binary tarball, used to install on top of another distro, for
>>     all “supported architectures” (Primary and Alternative).
> (...)
>
> OK, I can add them to the GCD.
>
> Just to clarify terms, I'm looking at the download page (https://guix.gnu.org/en/download/)
>
> What you're calling the "binary tarball" is that on the download page
> as the third option labeled "GNU Guix 1.4.0 Binary"?

Yes.

> I thought that was what I was calling the "GNU Guix installer".

Oh sorry.  To me “installer” refers to the Guix System installation user
interface on the ISO.

>>   • The source tarball, as produced by ‘make dist’ (target audience is
>>     primarily downstream packagers, such as Debian).
>> 
>
> On the download page this is defined as "GNU Guix 1.4.0 Source". I will add this.

Yes.

> We don't have anything about the downstream Debian/Fedora
> packages. Philip McGrath mentioned this as an important path and I
> agree. Since we don't create the packages I'm not sure what to do
> here. Ideally, we'd work with the packagers to co-ordinate with them,
> but as a project we don't actually create them.

Right, there’s not much we can do: they’re maintained by others.  Our
job though is to make sure they can take the source tarball (or a
checkout) and work from there.

> At Guix Days (2025) there was a big discussion about releasing. Efraim
> nominated himself as the first "Release Manager".
>
> I'm sure that there are others in the group would also be interested,
> there was a good discussion in December. I'm sure that Andreas and I
> would be excited to work on it!

Ah yes, excellent.

> And, I'm assuming _you_ are mentoring us all ;-))

Sure, I’ll do my best and maybe Maxim can share his experience too.

Thanks!

Ludo’.