Hi Ludo,
Thanks for the feedback and insights. On Mon, Jun 09, 2025 at 03:34:26PM +0200, Ludovic Courtès wrote: > 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. 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." Practically: 1. Package sets build on the primary architecture. All other packages are "best effort". 2. Testing and manual QA is only on package sets on the primary architecture. 3. Release artefacts are only made from packages within the packages sets and on the primary architectures. > 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. (...) Thanks for the context, that really helps. I believe the version Efraim's been working on is here: https://codeberg.org/guix/guix/src/commit/15e19a2d9206da8d1fe26f93573a41f16998462c/etc/manifests/release.scm 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). 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'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? > > ## 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"? I thought that was what I was calling the "GNU Guix installer". > • 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. 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. > 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? 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! And, I'm assuming _you_ are mentoring us all ;-)) > > ### 3. Release project start > > Start the project with weekly updates to guix-dev and regular meetings of > > the > > s/guix-dev/`guix-devel`/ > Thanks > > ### 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. (...) Understood. I have it now that in week 3 we identify things to be removed and notify everyone. In week 10 they are removed, so there's been a good long period of notification. > 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. (...) Agreed, the real work is not the actual GCD heh heh =-) Steve / Futurile
