On 19 May, Jelle Licht wrote: (...) > Steve George <st...@futurile.net> writes: (...) > >[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. (...)
I think you're pointing right to the heart of this proposal, and the main thing we should think about! I'm trying to create an intent, a rallying-cry, an impetus for the project's active contributors to attempt and prioritise doing annual releases. I believe it will help our existing users, potential new users and the project itself, for the reasons I set out in the Motivation section. But, as you point out we are a volunteer project - maybe "we" don't want to work on releases; find it stressful; or don't have enough participants. I have tried to reflect this at various points, and in the 'Cost of Reverting'. At an individual level none of our contributors _have_ to work on a release, they can continue to work in their team-branches. So yeah, I agree everyone should think about whether they want to try out annual releases. I also think that the only way to find out if it's positive (a goal) or negative (stressful) is to try it out. If it doesn't work for everyone we simply return back to releasing when we want to. (...) > > ## 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. (...) Yeah, both you and Efraim suggested this, I removed server/hosted from the list in the latest version. I've also focused it on the minimal experience. I tried not to get too far into the weeds with "release criteria" definitions or similar. (...) > > 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, To reflect your comment and some others I've reworded a bit throughout to try and express the focus on the initial install and initial experience: what _has_ to work for someone to install Guix and it not break. There could be more detail but I'm trying to resist the GCD becoming even longer. Also, I think the GCD should be about the main "design" and the implementers (each release team) have the flexibility to make specific decisions. Thanks for going through it - appreciate it - and hope the later version reflects your comments above! Steve / Futurile
