Hi Philip,
Thank-you for the comments. On Fri, Jun 06, 2025 at 03:13:30PM -0400, Philip McGrath wrote: > 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 answered the underlying "concern" in my email back to Liam (please see that): it directly addresses why this proposed change doesn't "impose work" on all developers. Also, that this GCD is "reversible" so if we can't achive regular releases there's no harm done and we fall-back to our current situation. That's why I think this is a "low risk" GCD. On the topic of identifying "audience" and "use-cases" we do have some data (from the Survey) that tells us who our users are and what they care about. Looking at the history of the project it seems that wide-ranging discussions struggle to achieve consensus or land-up off-track (see previous discsussions about releases, archive structure changes, etc). So I think the GCD process (with the goal of consensus) is going to work best if we discuss small chunks with concrete outcomes that we can directly work towards consensus. Lower down you bring up users that install Guix from a distribution package, I believe the best way we can address that sort of "audience need" through the GCD is to concretely propose somthing - for example a GCD to separate the Guix daemon's timing. > 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. > I believe (from hanging out in IRC) that the main use-case for our current "release" installers (e.g. ones on the Web site) is by new adopters of Guix. The Survey showed that about 50% adopt Guix as a distro, and 36% as a hosted package manager. Unfortunately, we don't have data on whether users use the "Guix package" from inside their distribution or whether they install through the binary installer on the Guix side. (...) > > 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. Agreed, it's a really nice approach. I would like to know more about what the Nix project has learnt so that we can see if it's applicable to Guix. I avoided suggesting any changes to the archive model as my understanding is that previous attempts failed. So I focused this GCD only on things that would make release easier. If we move forward on this GCD, then I think we should have a look at this kind of separation, this could give us the flexibility to satisfy the timign challenges. > >> 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. (...) This one is interesting to me as I'm in the same situation as you. I mostly use Guix on top of other distributions. But, the difficulty is we can't satisfy the timing of the two needs: 1. Guix installed *from* a distribution package, hosted on top of another distribution 2. Guix as a Linux distribution We are both an upstream (for a distro to package Guix) and a downstream (for us to package upstream software into packages). The Survey showed that about 50% adopt Guix as a distro, and 36% as a hosted package manager. So, overall I think the timing leans towards making it easier for Guix to be a Linux distro. It sounds like the longer-term solution is what you note above - Nix's approach of doing with separate daemon releases - we shoul consider that in a follow-up GCD. Thanks! Steve
