Hi Steve, Steve George <st...@futurile.net> 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’.
