Subject: Re: [bug#78332] GCD005: Regular and efficient releases

From: André Batista <[email-masked]>
Date: Fri, 16 May 2025 17:02:12 -0300

Hi,

sex 09 mai 2025 ï¿½s 13:53:39 (1746809619), [email-masked] enviou:
> Hi all,
> 
> It's been ~2.5 years since the last Guix release, which led me to think we should do another one! Initially, I was just going to see if anyone wanted to create a release project. But, before I knew it I was writing a GCD! ...
> 
> Below you'll find a proposal for moving to a regular release cycle.
> 
> Thanks to Andreas Enge, Ludovic Courtï¿½s and Efraim Flashner for their initial comments and insights. They've agreed to sponsor it - which means they agree with the general direction (but not necessarily with all aspects), and will help to 'garden' the discussion to move us towards a consensus on whether it's a good proposal.
> 
> This is a **draft** submission so I look forward to your consideration of it, thoughts and comments.
> 

First of all, thanks for this initiative, we're certainly in need of a more
structured and reliable release process.  I have no experience doing guix
(or any distro) release, so take or drop my comments as you see fit.

I'm not sure a GCD is the proper way to tackle the release issue.  As we say
here in the global south - where November is spring :) - "you are putting the
cart before the oxen", meaning its the oxen that should be dragging the cart,
not the other way around.

Since we've been having problems producing a release for the past years, I feel
that aiming to shorten the release time span before even having had a release
might not be the best way to achieve the proposed goal.  What happens if we
approve this GCD, but then no one assumes the roles of a release team?  How
could we "enforce" this GCD on a volunteer project?

Wouldn't it be better to first establish and organize a release team, with the
goal of releasing v. 1.5.0 as soon as possible and with the secondary goal
of establishing/documenting a release process/schedule for future releases?
IMO, this does not require a GCD, "just" people volunteering to the work at
hand.

In a sense, I agree with other comments here that maybe we should treat
releases as something less disruptive of our normal activities.  So, instead
of aiming to mimick what other - larger and more resourceful - distros do, we
could aim to do it in a way that is compatible with our own routines and
resources.

What I envision is something like:

1.  The release team focuses mainly on the artifacts.  Those should routinely
be automatically built, regardless if we are about to release;

2.  The relase team keeps a watchful eye on CI/QA for the build status of main
architectures and packages needed to build the installer and images for those;

3.  Once some major changes (linux-lts, gnome, toolchain, etc) hit master and
CI shows that those are good and the successful build percentage is on a
historical high on CI/QA for the major architectues, the release team proposes
a new release to guix-devel;

4.  Once proposed, any other major changes (anything that currently warrants
a separate branch) are delayed for two weeks;

5.  During these two weeks, the release team has the authority to revert any
breaking changes (new build failures) commited to master and everyone is
invited to test the latest beta-release artifacts;

6.  If no release critical bugs are found, the relase team adds a commit
tagging the new release with a news entry and a blog post summarizing the
main changes since the last release and publishes the artifacts;

7.  If release critical bugs are found and cannot be fixed in time, the
release proposal is withdrawn and people are invited to work on the rc-bugs
and major changes can be again merged to master.  Go back to item 3, but a
new release proposal can only be made if the already rc-bugs are fixed and
the major changes that were delayed at the time of the last proposal had the
opportunity to be merged.

Does that make any sense?

Cheers