Hi Greg, On 9 May, Greg Hogan wrote: > On Fri, May 9, 2025 at 8:54 AM Steve George <st...@futurile.net> wrote: > > > [...] > > Adding a slower-moving branch akin to Nix's stable could be an eventual > > goal as > > it would increase Guix's suitability for some users and use-cases [^2]. > > However, > > this GCD only sets out to implement regular releases which is a substantial > > change that would be a big improvement for our users. > [...] > > This is a proposal for a beautiful release process. The process is > detailed and well thought out, but without stability these beautiful > releases quickly decay to our status quo.
Thank-you for the kind words - my aim is to be pragmatic about what we can achieve. Taking a concrete step forward allows us to make progress and who knows maybe we can achieve more in subsequent steps. > And I agree that we do not > have the capacity to maintain two branches (though it could solve our > naming issue). > > 1) It seems a waste to synchronize around a point-in-time beautiful > release only to have this break on the user's first pull. And builds > will quickly break when the freeze is lifted and the backlog > unblocked. The alternative to a pull is to forego security updates for > a year until the next release. (...) I hope the initial user experience wouldn't be to "break on the user's first pull", since with annual releases we wouldn't have release artefacts that are 2.5 years out of date. And, we'd also degraft regularly which would be beneficial for all users. As you can tell I would _love_ us to be able to have a slower moving branch, but purposefully have kept the GCD more limited. For now focusing on the step forward of regular releases. > 2) The project is currently unable to keep up with the teams workflow, > and now we are introducing an additional, quite long pause into the > calendar. > I agree this is a problem, for the purposes of focusing discussion on this GCD lets keep it out of the remit. Perhaps a separate discussion or separate GCD! > 3) Package cleanup is a problem that I believe we are afraid to > address. I agree that we should not have package "ownership", but > perhaps "sponsorship" or (to borrow from this GCD) "advocate" with > notifications when builds break on CI. I believe this proposal is too > aggressive in pruning packages without considering alternatives (in > another GCD). Can you point me to the part where you think it's too aggressive? Maybe it's overstating it in some way. In my mind I think the release is a checkpoint where we can use the package sets and the project plan focus to do what we should be doing using our existing process. > I think we should greatly reduce the scope and initially try (as I > noted in December buried in the "On the quest for a new release model" > discussion) creating a release team which would: > 1) operate as any other team > 2) be responsible only for building and improving release artifacts > 3) operate with a cadence sufficient to build and retain this > expertise (which would currently be one cycle of the queue, but > ideally every ~3-4 months) > > By using the teams queue everyone will know when the release is > coming, and whether their branch will be merged before or after the > next release. In a way this does create a team in the way you brought up in December [0]. It creates a "release team" for one project and tries to limit the "toil" by keeping the project to 3-4 months of effort. It defines a specific time when a release will happen so everyone knows when it's happening, can get involved and help. Where it differs is that realistically the release artifacts involve the kernel, core packages, networking, base utils, guix daemon, and graphical environments [1]. I don't think this can be done by 3-4 volunteers, there has to be some co-ordination and energy from all teams - we are a small team after all! Does that address your concerns? Steve / Futurile [0] https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00205.html [1] https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm
