Reflections on the release process

[Ludovic Courtès]

Hello Guix!

The release process is long and tedious.  I’m super happy we made that
release and did a lot of work collectively testing and fixing things,
but I thought I’d share my frustrations while it’s fresh in memory so we
can brainstorm and make it better for next time!


1. “make release” requires ~6 hours to build everything.  You have
to have offloading enabled and the connections have to be stable all
along.  In total it builds the ‘guix’ package six times (once for each
binary tarball, then once for each ISO image).

2. “make release” commits to update ‘guix’ and these commits are signed
because that’s our Git config.  That means gpg-agent must not forget
your passphrase during that time or the process will stop in the middle.
I work around that by temporarily increasing gpg-agent’s
‘default-cache-ttl’, only when I’m at home and near my laptop, but it’s
obviously not great.

3. ‘guix’ in the ISO image can install 1.1.0 precisely, but that means
that the commit that defines 1.1.0 has typically not been picked up by
ci.guix.gnu.org (or we’d have to push it explicitly).  So you have to
manually get berlin to build it afterwards or anyone installing Guix
System will build from source.

4. We lack a clear way to mark bugs as release-critical.  I’m really
happy Florian, Mathieu, and I have been able to work together and squash
bugs one by one (thank you!).  Still, it would have been better if we
could have tagged which is release-critical and which is not, to prevent
misunderstandings such as regarding the NVMe bug:
<https://issues.guix.gnu.org/issue/40590>.  Can Debbugs help?  The GCC
folks have a system that sends email with an update on the number of
release-critical bugs.  I’m sure we can learn from how others deal with
that.

5. With the installer, we have to test on actual hardware, and that
necessarily takes time.  Thumbs up to everyone who tried the RCs and
reported back!  Perhaps we need to make time for more RCs in the future.
Yet, we probably don’t want the frozen branch to live for too long, so
that should still be fast-paced.

6. Writing release notes, announcements, etc. takes a lot of time.



Part of the pain for 1–3 is due to the insane amount of time it takes to
build Guix entirely.  That’s mostly work to be done on Guile’s compiler,
which is a top priority for Guix.  Perhaps there are also things we can
do on the Guix side, such as arranging for ISO images to use a Guix
built with (guix self) rather than a ‘guix’ package to rebuild build
times.

For the other issues, I’m interested in any ideas you may have!

Until then, big thanks to everyone who helped out over the months and
especially over the last few days—now it’s party time!  :-)

Ludo’.