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