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

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

Hi Noé,

On 22 May, Noé Lopez wrote:
> Steve George <[email-masked]> writes:
(...) 
> Hi Steve,
> 
> Thanks for this great GCD!
> 
> I assume the GCD would end after June, so will there be a july/august
> release or will we have to wait for a year?
(...)

Asking other developers about timing the general sense was that asking volunteers to contribute to a release over July/August wouldn't work because everyone is on holiday (and hopefully doing something better than staring at their screen!).

Rather than wait a year I proposed:

> > This GCD proposes an annual release cycle, with releases **in June**.
> >
> > To move onto this cycle the first release would be a little later: aiming for
> > the **November of 2025**, with a short cycle to release in June 2026.

Essentially, this would mean we'd start working on a release in the Autumn. 

(...)
> > The Release Manager role is likely to require the most effort, so it will be
> > rotated and consist of two people from the release team.  For each release
> > there would be a primary person and a secondary person in the role.  The
> > primary person is new to the role.  The secondary person has previously done it
> > and is mentoring the new person.  The impact of this is that each new release
> > manager is agreeing to take responsibility during two release cycles.
> > This system is modelled on the [Nix release management](https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md)
> > approach.
> 
> What happens in 6 years when there are no new release managers
> available, can we reuse someone?
 
I wasn't suggesting a strict rotation where you can only do it once out of the X committers that we have. The new person is still a volunteer from the pool of committers. The idea of the "rotation" is to prevent it becoming one persons permanent chore and because of the 'bus-factor' risk. I expect that there will be a subset of active contributors who are interested/willing/able to work on a release, so the 'release manager' role will probably rotate around amongst that group - but not all contributors.

In principle, if we did get a lot of automation the RM role wouldn't have to be a committer, but as I understand it at the moment it does.

Fixed the other typos - thanks for going through it in detail, appreciated!

Steve / Futurile