Subject: Re: GCD005: Regular and efficient releases (submitted)

From: Steve George <[email-masked]>
Date: Thu, 22 May 2025 10:11:38 +0100

On 22 May, Efraim Flashner wrote:
> On Wed, May 21, 2025 at 06:10:13PM +0100, Steve George wrote:
(...)
> > A specific issue caused by irregular releases is that new users/installs face a
> > significant first "guix pull". This provides a poor initial user experience,
> > and in some cases may even deter users [^4]. Additionally, it requires the
> > project to keep old substitutes on our servers.
> 
> I think the guix pull issue isn't related to the release cadence but due
> to the size of the git repo and the number of authenticated commits.
> There's definitely work to be done to speed up the first guix pull, but
> I don't think it belongs in this GCD.  How about:
> 
> A specific issue caused by irregular releases is the time-bombs which
> exist in a number of packages and their test suites.  People installing
> from a release tarball often find that important packages fail to build,
> making their initial attempts to use Guix unnecessarily hard.  There are
> also the issues of disappearing upstream sources and the need to keep
> old substitutes on our servers.
> 
> People using Guix on a foreign distro also often use the guix-daemon as
> packaged by that distribution.  This means that any daemon related
> changes, such as a change in the compression algorithm of the
> substitutes or changing substitute servers can only be considered
> complete after the guix-daemon has been updated in those distributions
> as well.
(...)

Yes, fair enough that's more specific and clear. Added it.

(...)
> > ### Branch and tag release branch (week 09)
> > The master branch is tagged and a new release branch is created.
> > 
> > * master branch: security only.
> > * release branch: security updates as normal. Only RC blocking bugs.
> > 
> > Only security updates go to the master branch from this point.  All other
> > changes stay in a team branch or go to an integration branch.  The focus on the
> > release branch is to stabilise so only resolutions to bugs should be pushed.
> 
> I'm still not entirely sure about the branches.
> release-branch: security, RC bugs and where the release is prepared
> master branch: security only
> next-master: everything that would've gone to master
> 
> Looking at some of the other bits of appendix 1 I'm better able to wrap
> my head around something like:
> 
> release-branch: where the release is prepared, with merges from master
> master branch: security and RC bugs
> next-master: everything that would've gone to master

Given that the main purpose of the 'release-branch' is to track the final release artifacts I think we can do it either way around.

So, either:

- do work in master and sync to release at the end
- or work in release and sync to master at the end

I've updated to your scheme and tried to provide a short explanation, without lengthing this area too much!

(...)
> > ### Testing and Hard Freeze (week 10)
> > Release Crictical (RC) bugs and issues should be solved for the release branch.
> > 
> > Only changes that will fix a non-building package, or a RC bug in a
> > package/service are allowed.  Ideally avoid new upstream versions, but it's
> > acceptable to use a new minor upstream version to solve a bug.
> > 
> > Any non-building packages are removed using the Deprecation Policy.
> 
> perhaps add: As always, packages can be un-deprecated at a later date.
> 

Done.

> > ### Alternative release target #2 (week 16)
> > This release target date may be used if the Release Team determines that there
> > are Release Critical bugs without workarounds at one of the previous target 
> > dates.
> > 
> > If the Release Team determines that the release has Release Critical bugs
> > without workarounds they may move the release to an alternative date or cancel
> > the release.
> 
> I do like that there's a built-in "release or pass" time period where we
> can punt on the release and try again at another date.  We don't want
> the possibility of a freeze dragging on for months.
> 

It also speaks to Jelle's point, if the project doesn't have the volunteers to complete the release then we can just move on.

Steve / Futurile