Hi, Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
> Efraim Flashner <efr...@flashner.co.il> writes: > >> On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote: >>> Ricardo Wurmus <rek...@elephly.net> writes: >>> >>> > Efraim Flashner <efr...@flashner.co.il> writes: >>> > >>> >> Since, IMO, the major uses of the actual guix package is for the daemon >>> >> and the installer, I think we could tag a minor release just about every >>> >> time we bump the guix package. >>> >>> That's a sensible approach. How should the discussion proceed further? >>> Do we have a proxy to determine whether everyone who needs to be >>> involved for consensus-based decision-making has weighed in? >> >> I'd argue that cutting releases is one of those specifically maintainer >> duties but I'd love to hear from other people who disagree. > > I'd tend to agree. A maintainer who doesn't cut releases or organize to > make them happen is a poor maintainer (hello!). Heheh. :-) As has been discussed multiple times at the Guix Days and on this list (I think?), I believe what we need is a release team with rotating duties. That is, a bunch of 3–5 people commit to doing the work leading to 1.5.0; then a new team (possibly with overlap) takes over for the next version, and so on. This is what NixOS has been doing for some time, for example, and it has several advantages: it distributes responsibilities and power, and it ensure everything is properly documented so people can actually carry out the task. As mentioned previously, I’m happy to mentor and help whoever steps up. I know there are people up to the task; at least one person on the team needs to have commit access, but apart from that, don’t be shy! Our first exercise will be to make a “fake” release as a way to test documentation and find out about missing bits and corner cases. Ludo’.
