Hi, I share the concerns others have already described, particularly:
On Fri, Jun 6, 2025, at 12:41 AM, Liam Hupfer wrote: > I tend to agree with Andrew’s feedback > (<https://yhetil.org/guix-patches/87ikly5t74....@trop.in>) 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. > To me, it seems important to clearly identify who is the audience for Guix releases and what use releases are meant to serve. I primarily use Guix as installed through the Debian packaging, so, to me, foreign distro packagers are obviously an important audience! Some form of Guix System installer also seems important, but I'd hope to hear more from interested people about what use-cases releases, as opposed to snapshot installers from CI, serve in that context. > 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? This discussion calls to mind that the Nix folks (IIUC) have a release cycle for their daemon that's different from that for their package set. >From my perspective, the daemon and other software developed by Guix are the essential part of a release. Narrowing the scope and defining the audience might make it feasible to provide relevant security backports, an extremely valuable improvement. >> 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? > > ... > > 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. > Overall, I also think this concept of "package sets" should be simplified and refined, or indeed replaced by existing concepts like teams and manifests. For Guix on a foreign distro, "kernels, boot loaders, [and] filesystems" don't actually seem relevant as part of the release. For the installer use case, again, I think it would help to clearly articulate the audience and purpose of releases. For example, one possibility (which may or may not make sense) might be, "A user who does not have command-line experience should be able to install Guix, boot the installed system, and use Emacs-Guix to execute `M-x guix-pull`." One reason that possibility might not make sense is that I'm not sure how completely Emacs-Guix replaces the need for command-line experience. If Guix effectively requires command-line experience already, I'm not sure *any* desktop environment should be a release-critical package. (To be clear, I think it's very valuable to support users who don't use the command line, I just think we should be clear about whether we currently do or not.) With the context in mind that a better release process wouldn't replace the recommendation for an immediate `guix pull`, I also think the discussion of timing with respect to other distros and desktop environments is backwards. If Guix releases in June, packages of Guix in Ubuntu LTS (April of even-numbered years) and Debian Stable (c. summer of odd-numbered years) will be 10+ months old at time of release. The proposed benefit of getting a more recent desktop into a Guix release seems minimal: users on foreign distros will not use it at all, and Guix System users who follow our recommendation will use it only until their first `guix pull`. It would seem better to release in November or January to get an up-to-date Guix into LTS distros. Hope this is useful, Philip
