Re: Planning for a release, for real

[Julien Lepiller <julien@lepiller.eu>]

[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]

I'll take care of the cranslations (notifying translators, ensuring string freeze is respected, …)

We need to be careful not to start the stsing freeze step too early. Last time (or previous?) we started a week before the scheduled release date, but the schedule slipped by a few weeks and we had some pressure in the pipeline because some patches could not be applied because of string changes.

Let's try to have a better vision on the planning this time :)

Le 6 octobre 2022 16:50:22 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello Guix!
>
>Will Guix’s 10th year be a release year?  I hope so!
>
>We need to plan and coordinate.  Releases have to be a group effort;
>some of the most important work won’t be coding but coordination.
>Coordination is key.  I don’t think I should be spearheading that
>effort, but I’m happy to be part of it.
>
>Who’s ready to commit time towards that goal for the coming weeks?
>
>Here’s a list of things to do to get there:
>
>  • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
>    a couple of weeks ago, but then I lost track of it.  Marius?
>
>    We need a ‘staging’ champion to keep track of what’s left to be
>    done, reports progress, pings people, etc.  That person does not
>    have to be hacking like crazy, on the contrary!
>
>  • Get base binaries on all supported architectures in a timely
>    fashion, or drop some of the architectures.
>
>    Namely, ‘make assert-binaries-available’ is currently failing.  It
>    uses a manifest that encodes what we consider to be the basic
>    requirements for each architecture; it’s not demanding for
>    aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
>    meeting these criteria yet.
>
>    We need to look at missing substitutes, address build issues and
>    build farm issues that cause them until we get to zero failures.  If
>    after some effort we fail to get to zero, then we should consider
>    dropping architectures (I’m looking at armhf-linux and i586-gnu
>    specifically).
>
>    Again we need a champion to keep track of this and ping people so we
>    make progress!
>
>  • Address the blockers of <https://issues.guix.gnu.org/53214>, most of
>    which are issues in the installer.
>
>  • Freeze strings: enter a period where translatable strings in the
>    code and in the manual must not be changed so translators have a
>    chance to keep up.  Julien, how would you like to do that?  Weblate
>    has given us more flexibility it seems.
>
>  • Publish a release candidate and call for testing of the installer in
>    particular.  Fix bugs, loop.
>
>  • Update NEWS (mostly done already!), prepare a blog post listing the
>    highlights and linking to the relevant material.  (See
>    <https://guix.gnu.org/en/blog/tags/releases/> for inspiration.)
>
>I’d like us to do this with an eye of getting better organized, which
>involves defining roles such as that of “release managers”.
>
>The NixOS folks handle this in a way that I find inspiring, with
>rotating release manager responsibilities, a schedule announced upfront,
>and a detailed description of the process:
>
>  https://github.com/NixOS/nixpkgs/issues/193585
>  https://nixos.github.io/release-wiki/Home.html
>
>We have
><https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org>
>but it’s low-level and dates back to a time where release were a
>one-person activity.  Time for a change.
>
>So, who’s in?  Let’s get our act together!
>
>Ludo’.

[-- Attachment #2: Type: text/html, Size: 4327 bytes --]