Hi, Greg Hogan <c...@greghogan.com> writes:
> On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès <l...@gnu.org> wrote: >> 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. > > So a release team like every other team? An etc/teams.scm team (as > opposed to a mailing list team) also promotes the notion that much of > the needed work is outside of the release process. There were several > ideas for improvement earlier in this thread, but for another I > noticed that NixOS provides AMIs. If someone was to create the > necessary scripts and documentation for publishing Guix release AMIs > it would be handy to have a team to guide that contribution. It could be an etc/teams.scm team, although these have so far always existed with a scope of files, that works in conjunction with 'git send-email' to notify people of modified files. I don't have anything against the idea though; they'd at least serve as a record of who to contact for some scope of responsibility. >> 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. > > Looking through doc/release.org, much of the work should be the > responsibility of other teams. NEWS could be updated when team > branches are merged. That's a low hanging fruit that would greatly help picking to ease the work of producing a new release: some new contributing guidance that would mention new significant features should have an entry written in both the NEWS file and etc/news.scm. -- Thanks, Maxim
