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

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

Hi André,

Appreciate you going through it and more broadly suggesting how you think a release system could work.

On 16 May, André Batista wrote:
> 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.
(...)

I want to take on the underlying reason for why I believe we should have a GCD.

Like you point out I initially intended to "just do a release". - I was going to email guix-devel asking "who wants to work on a release".

Then I realised that there'd been a few attempts at this in the last 2.5 years, and previously the project had infrequent releases compared to the vast majority of distributions. That changed my mind.

I submitted the GCD because I'm trying to get us as a group to think about whether we want to do regular releases. The GCD lets us choose whether we're motivated to prioritise achieving releases.

The specific details of whether it's annual, whether it's in May or June, whether we use a particular branching strategy - all sit on the foundation of whether "as a project" our goal is to release new versions regularly.

Explicitly, what this means is that _all team members_ value regular releases: it's not about what 4 people in a release team do, it's about having a goal as a project.

This does not mean that any individual volunteer has to actively work on a specific release. Of course, I hope that more people across the team would be excited by the idea of a release and contribute, not just leave it to the 4 people in the 'release team' to try and fix everything. Nonetheless, some people aren't interested in actively working on releases, which isn't a problem. But, at a mimimum adding a public cadence means that everyone has the clarity that we value regular releases and therefore there there are impacts at certain times - for example, developers can't destabilise a release by shipping something major a day before a final release.

If releasing regularly is priority goal for a project, I believe time-based releases are the best choice because:

* clear goal - everyone knows that in $DATE there's a release so know's what to work on.
* rhythm - naturally you work on big changes at the start of the cycle, and smaller ones close to the end.
* efficiency - you get better at what you do often: if we want to "automate" releases we can only find what works if we actually "do" releases.

Having worked in a time-based system I can honestly say that if you care about shipping something to users it's absolutely the best way.

The new version of the GCD integrates the comments about aiming for automation, that you and a few others made. Everyone has different experiences with releases and different definitions of what quality level is acceptable - overall the later version tries to minimise the work, but I will say "it builds" is not the same as "it works" for a distribution, at a minimum some humans will have to actually test the installer and first user-experience.  I added a kinda-sorta version of what you/Vagrant mentioned where if we're not in a releasable state then we move forward to a later target date - helping to balance quality and time-based discipline. I also added a goal of automation to the overall GCD and to the release-teams responsibilities in-line with what you/Greg/Ekaitz requested.

Hope this explains the thinking a bit more, and that the new version somewhat reflects your comments,

Steve / Futurile

> 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