Subject: Re: GCD005: Regular and efficient releases

From: Greg Hogan <[email-masked]>
Date: Fri, 9 May 2025 11:35:01 -0400

On Fri, May 9, 2025 at 8:54 AM Steve George <[email-masked]> 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. 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.

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.

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).

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.

Greg