Hi Liam, On Thu, Jun 05, 2025 at 11:41:22PM -0500, Liam Hupfer wrote: > 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.
It's really valuable to have other perspectives, so thanks for getting involved in the discussion. We're new to trying the GCD process, so getting input and learning how we move towards consensus are all part of it. > 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 whole heartedly agree with not "[imposing] processes ... that the volunteer community can't properly support yet". I really want to remove your word "imposing" because no contributor will be *forced* to be involved in working on a release - I want to make sure that's 100% clear - nothing is being imposed. If an individual developer isn't motivated to work on releases that is totally fine and acceptable: the only thing they're really being asked is "not to prevent others" from working on a release. Aside from that, I agree that _any_ change in our processes brings risk that we don't know if we can "properly support". We don't know if we have enough "volunteer community" time/energy to do annual releases. One way to consider that risk is to think about whether a GCD is irreversible (a one-day door). Trying 'regular releases' is not a one-way door. We can try it out, and if it turns out that we can't manage it as a project we'll simply fall back to our current process of irregular releases. I would strongly advocate for us to have an experimental mind-set, where we generally lean towards the changes proposed in GCDs. If we aren't willing to try out a different <whatever>, we'll get the same result. And, really the only way to learn is to try something out and find out - we can iterate from there! We should be "judicious" and thoughtful (so I'm not calling for chaos!), but I do want to encourage us to be positive about trying different approaches (particularly if they're reversible). (...) > 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. (...) Many distribution teams used to work on the "when it is ready" model. But, release projects are famously exhausting for distribution teams. Most projects have struggled to ship and burnt out teams. Time-based releases came about to basically reprioritise "ship it" over features. At some point in every release project you have to say "we've done all we can on features, now we test and then we ship it". From my experience, if a release team can't ship, their chances of shipping start decreasing rapidly. So overall, I would say if we can't ship in X attempts (landing zones) let the team decide what to do - in all probability they will be best to disband and try again later. I wouldn't be in favour of going to "when it is ready", but adding some flexibility through "landing zones" seems like a good bit of flexiblity that can account for the challenges of 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 > > 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? Heh! You really set me thinking here trying to figure out why distributions split like this. For the record, Efraim's the only person working on this and right now the "release" set your suggesting is what we'll land up with. So, why have I tried to split it like this? First, we have to have a concept separate from a "Team", because we're not "imposing" a requirement on a Team to delivery for a release: if the installer uses some Python libraries we do *not require* the Python team to package, test, deliver etc. We need some way to separately track what's in the release so we can test it and reduce the amount of work we're covering. I split it into "minimal" and "desktop" because we have at least two scenarios: 1. Minimal: guix installed on a hosted distribution, minimal guix installed as Linux distribution 2. Desktop: Guix installed as a Linux distribution with a specific DE This is mostly about the testing and focus of the Release Team's attention. Having a minimal/desktop split makes it easier to add other testing scenarios (e.g. minimal->"server"). However, right now Efraim's work is doing what you suggest. > > - 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. The context for me is that we have a lot of broken packages and the release is a sensible time to look at them. The Survey showed that, out of date and broken packages are a big problem for users, so my thinking was that during a release project it's natural to reduce our scope by going through the process of notifying Developers that packages will be removed. We don't actually have that much knowledge about Nix's processes and approach. How do you see ZHF working and do you have any thoughts/knowledge on how Nix deals with broken packages practically? (...) > > - 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. (...) I put in both package sets and the architecture section as ways to reduce the scope of a release. So my goal was to figure out ways to reduce the friction of doing a release. Hypothetically, a release requires us to test every package on all archectures - obviously that doesn't actually happen! So how can we be explicit about what the Release Team must work on - one way is to say "we don't work on or test these packages" (package sets) and an additional way is to say "we don't work on or test these packages" (architectures). > > # 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. (...) In general, the "freeze" has had the most negative attention. I will say my personal experience having working on a lot of releases is that the main thing that prevents a release of a Linux distribution is a developer committing somethig that breaks the entire archive a few days before the release. There's an example from NixOS in their document, Debian famously has had it, at Ubuntu I can think of two instances. > > | -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! > Yeah, I'll change this, you're right "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? (...) This is from Efraim who believes it will be easier to merge from master into a release branch. It's essentially designed to do what you're suggesting by limiting the time period of any freeze on master, while ensuring the artefacts from the release aren't going to be broken on first pull. > Sorry for the scattered email. Hopefully you find some of it valuable. > Thanks again for your work on this! I didn't address all your points, but thanks for the detailed feedback! Maybe you'll be interested on working on the first Release Team <hint> <hint> ;-)) Steve / Futurile
