Hi Steve, Guix, First, thanks for moving the discussion forward here! Release discipline is one of the marks differentiating a toy project and a serious one.
I am not a regular contributor yet but am an active user and list lurker and have some impressions of current pain points. I also hang around Nixpkgs and contribute there (mainly helping with the Guix package and services) so I have some familiarity with their processes. 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. The GCD doesn’t discuss tagging conventions but it came up in discussion. Even if we move to a strict time-based schedule as is proposed, I am a bit concerned about calver since it gives users the impression of stable branches based on how other distros (NixOS, Ubuntu) use calver. Sticking with semver until we can support stable branches feels worth considering. I do like the “when it is ready” model Vagrant mentions from Debian. Once we agree to start the release process, readiness of a minimum viable package set can dictate the time to release. I’m not opposed to the landing zones you wrote down but I also don’t think they’re necessary to make explicit. If a bug considered release blocking exists, the release will be postponed until it is fixed (a tautology, I guess). Nothing wrong with having a planned schedule but it can be kept simple and we can note that it’s not a guarantee. > 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? > - Coverage: all packages and services that are not explicitly platform > specific must work to be included in the archive. So any package or service in the entire repository that doesn’t build on a primary arch must be removed before the release? Based on how Nixpkgs ZHF goes I’m not sure this is realistic. Do you mean packages and services in the release set? There are a lot of random leaf packages that aren’t release critical but can become unmaintained as time passes. As more services are added this is likely to become the case there too. I’m not sure the release team should be burdened with hunting all these down. A time-based best-effort cleanup period like ZHF every release is certainly valuable, though. > - Package status: package updates should build for this architecture. If a > package update is broken it must not be pushed to users (e.g. master). > - Security: all packages that are maintained upstream receive updates These points don’t seem related to releases but rather general policies about master? I guess you are defining the architecture tier concept here but this was confusing to me at first in the context of reading the GCD as a whole. > # Appendix 1: Release Project Template I know the appendix is just an example (“non-normative” in spec parlance) but I feel like it warrants review if it’s going into the GCD as reference material. We should keep it concise and can get more elaborate when planning the first release after the GCD is approved. I do not think the major updates freeze and hard freeze are both necessary. I think given the discussion on limiting the scope of a release effort, we don’t need to bother with freezing all major updates in week 8 for all packages, just the ones in the closure of the release set. If particular maintainers want to keep shipping R or Haskell or Emacs package ecosystem updates during the release we should let them IMO, trying to approach a pristine full package set is not feasible yet and we don’t want to encourage people to stay on tags anyway. An informal cleanup period seems fine but a formal global freeze seems to impose too much on niche package ecosystems maintained by volunteers that ultimately won’t affect the release artifacts. > | -5 | Nominate a release team | > | -4 | Notify teams of upcoming release | > | 01 | Release project start | The use of negative indices gets confusing when the start is week 1. Is there a week 0 or not? IMO the NixOS example where release week is 0 is intuitive. Countdown to release! > ### Toolchain and transition freeze (week 04) > No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes > (e.g. java). There should be no changes that will cause major transitions. > Debian defines a transition as one where a change in one package causes > changes in another, the most common being a library. This isn’t suitable for > Guix since any change in an input causes a change in another package. > Nonetheless, any change that alters a significant number of packages should be > carefully considered and updates that cause other packages to break should be > rejected. If Debian defines the term “transition” in a way that makes it meaningless for Guix, we shouldn’t reuse it. I don’t find it a very intuitive term anyway. Maybe “mass rebuild”? I know I’ve seen that term before in Guix contexts. Regardless, I don’t think restricting mass rebuilds for 8 weeks is viable. If we focus on the release set as is being discussed I don’t think we need to care about mass Haskell or R or Emacs rebuilds. > This concept comes from the Nix project where they flow big changes into a > staging branch while they do release stabilisation to prevent big flows of > breaking changes into master which broke one of their releases [^6]. The proposed branching model is not that similar to Nixpkgs, I think. In Nixpkgs they don’t bother with a next-master because master is only restricted for ~3 weeks. While merges to and from the Nixpkgs staging branch are affected by the release process, the branch itself is not really tied to release stabilization. It is for grouping mass rebuilds and is used outside of release time too. I think we should drop the reference since next-master as it is proposed here is not really related to the Nixpkgs staging branch. IMO we should drop the discussion of this next-master integration branch from the GCD and revisit it if it seems necessary during a release. In the context of the proposal to not freeze non-release critical package ecosystems it makes sense to me, anyway. > * release branch: regularly merged from master, tracks the release artifacts. > * master branch: receives security and resolutions of RC bugs. > * next-master: everything that normally goes to master. Why is the release branch created while master is still frozen for 3 weeks? Sorry for the scattered email. Hopefully you find some of it valuable. Thanks again for your work on this! —Liam 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. 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?
