Hey folks,
Steve George <st...@futurile.net> writes: > Hi all, > > It's been ~2.5 years since the last Guix release, which led me to think we > should do another one! Initially, I was just going to see if anyone wanted to > create a release project. But, before I knew it I was writing a GCD! ... it happens to the best of us ;-). Thanks for working on this! >[snip] > Many desktop distributions release every six months to align with the major > desktop environments (GNOME/KDE) who release two or three times a year. This > is > why Nix (May/November) and Ubuntu (April/October) align their releases. I think that this is a good point to make, but at the same time we may not want to have other projects to direct our release cadence. Not because we don't want to play along, but rather because it causes undue stress and adds arbitrary deadlines that are hard to work around w.r.t. our current volunteer group of contributors. > Since Guix is used [extensively as a desktop] > (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/) > it would make sense to align with these upstream releases. However, given > that > Guix is a volunteer project that doesn't have the practise of releasing it's > unrealistic to move to two releases a year. Something along these lines could > be a future goal [^5]. > > This GCD proposes an annual release cycle, with releases **in May**. > > To move onto this cycle the first release would be a little later: aiming for > the **November of 2025**, with a short cycle to release in May 2026. > > > ## Package Sets > > There are currently over 30,000 packages in the archive, it's unrealistic for > all packages to receive the same amount of QA effort for a release. > > Many other distributions focus attention on the critical parts of their > repository by identifying those packages that are required for a particular > user-case. For example, Arch Linux limits their efforts to a specific > repository (called "main"). Ubuntu identifies various seeds for specific > use-cases which determines their maintained packages; other packages outside > these sets do not receive security updates. > > Guix is both a package manager that can be hosted on other Linux > distributions, > and a Linux distribution. Limiting the range of packages that receive > attention > is consequently more complicated. Guix already has manifests to track which > packages are used by [Guix System's > installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm) > , so this proposal extends that concept. > > For this proposal Guix would identify key package sets which would receive the > most attention for QA'ing a release. > > 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. My two cents: focus only on minimal, perhaps extended in such a way that this is a system that after the first reboot allows one to run guix pull. Ditto for 'foreign-guix': any version of guix that doesn't burn down the house on updating itself seems like it would be 'enough', and still a strict improvement over the current situation. > Guix would still make all packages and services part of a release (the entire > archive), but only those in the `package sets` could block a release due to a > significant bug. The goal would be for this to be as small a set of packages > as reasonably possible. It would mean that developers could focus on the > critical packages and services during a release. As an example, this would > mean that a major issue in the Linux kernel could block a release, but not an > issue in a game. This makes a lot of sense to me, although I could be centered around 'functional' breakage w.r.t. allowing the installation to update itself past any major issues via guix pull (+ guix system reconfigure or equivalent). > [snip] Thanks again for the detailed analysis and proposal, - Jelle
