Hi Steve,
Thanks for the hard work on this crucial aspect of the project.
Some wondered about the indented audience of releases. To me it’s quite
clear that it’s manifold: there’s public relation, yes, but also
downstream packagers as mentioned, and perhaps more importantly, any new
person installing Guix, be it standalone or on another distro. Starting
today from 1.4.0 makes for a terribly bad user experience.
Some more specific comments:
> 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
> things like X11/Wayland, desktop environments, key applications and themes.
> * server: provides packages and services for a server. This would include
> standard server packages and services.
> * hosted: provides packages and services which are necessary in hosted usage.
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.
For previous releases, there were really two package sets of sorts,
although that wasn’t formally specified:
• Packages that the Guix System installer would offer had two build on
the two architectures for which images were provided (i686-linux and
x86_64-linux). That includes core packages but also things like
Xfce, GNOME, Tor, ntpd, and other things that can be selected from
the dialog boxes of the installer.
This is ‘%system-packages’ in ‘etc/manifests/release.scm’.
• “Core” packages that anyone may wish to install on any of the
architectures supported by Guix (not Guix System).
This was ‘%base-packages’ in
<https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de644d4972db374f4f/etc/manifests/release.scm>
(not sure why it’s not there anymore).
The former had to be build on x86_64-linux and i686-linux; the latter
had to build on all architectures listed in ‘SUPPORTED_SYSTEMS’ in
‘Makefile.am’, and also listed in the manual:
https://guix.gnu.org/manual/devel/en/html_node/GNU-Distribution.html
I would tend to formalize on these two package sets and associated
requirements.
> ## 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).
• The source tarball, as produced by ‘make dist’ (target audience is
primarily downstream packagers, such as Debian).
Reducing toil will be a matter of defining “supported architectures” in
a reasonable way.
> ## Release team and project
I really like this section!
> ### 1. Nominate a release team
> Nominate a release team with two Release Managers (1 is the previous RM), and
> up to 4 other people who will work on the release. Put out a call for a
> Release
> Advocate who can be anyone in the Guix community who's willing.
This raises the question of who will nominate the team. But perhaps
that’s a problem mostly for the first release (Nov. 2025) since after
that passing on the torch will be easier?
> ### 3. Release project start
> Start the project with weekly updates to guix-dev and regular meetings of the
s/guix-dev/`guix-devel`/
> ### 8. Breaking changes to staging
> To avoid a period of time where teams can't commit breaking changes, these are
> sent to a new 'staging' branch, rather than directly to master. The master
> branch slows down from this week.
In the past, what we did was to create a ‘version-1.4.0’ (or similar)
branch one or two weeks before release and would let ‘master’ live its
life, avoiding both total freeze and unintentional breakage while we’re
close to release (only people working on the release would commit to
that version branch).
The version branch would be prioritized by ci.guix.gnu.org too.
It’s very similar to what you wrote here but by keeping the default
unchanged for developers not part of the Release Team, it may prove to
work better.
> ### 12. Testing and Hard Freeze
> RC bugs and issues should be solved for the release branch.
>
> Only changes that will fix a non-building package, or a bug in a package are
> allowed. Ideally avoid new upstream versions, but it's acceptable to use a
> new
> minor upstream version to solve a bug.
>
> Any non-building packages are removed.
According to the deprecation policy, this can be done anytime but takes
at least one month.
Overall I like what the GCD lays out. Perhaps there will be adjustments
to be made here and there but it looks sensible to me.
I expect that a big chunk of the work before the November release will
be streamlining the process, in particular ensuring that a developer can
make a release without having too many privileges or a
multi-architecture build farm at home.
Thank you!
Ludo’.
