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
signature.asc
Description: PGP signature
