unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Reflections on the release process
@ 2020-04-15 20:16 Ludovic Courtès
  2020-04-17 12:46 ` zimoun
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2020-04-15 20:16 UTC (permalink / raw)
  To: guix-devel

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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-04-24 16:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-15 20:16 Reflections on the release process Ludovic Courtès
2020-04-17 12:46 ` zimoun
2020-04-22 20:09   ` Ludovic Courtès
2020-04-24 16:06     ` zimoun
2020-04-24 16:45     ` Gábor Boskovits

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).