Hi Noé, On 22 May, Noé Lopez wrote: > Steve George <st...@futurile.net> 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
signature.asc
Description: PGP signature
