Subject: Re: GCD005: Regular and efficient releases

From: Andreas Enge <[email-masked]>
Date: Tue, 13 May 2025 14:56:17 +0200

Hello Ekaitz,

Am Sat, May 10, 2025 at 01:04:18PM +0200 schrieb Ekaitz Zarraga:
> So, now, realistically speaking, we are not ready for total automation and
> we should make a release process. That I agree with, and we could use the
> process to try to slowly make the process lighter until it barely exists,
> which would at some point let us make releases more often and with lower
> effort.
> (...) I'm thinking on how could we share
> the responsibility to make the work of those that are going to make the
> release as light as possible.

I think this is something we agree upon: Things should be as automatic
as possible, if we can make machines do the work for us, this would be
perfect!

But clearly this is not easy. Given past problems with CI and QA, we see
that there are not enough people working on automation, and that the
problems are complex.

> I'm a little bit pessimistic about how many people would get involved in
> that, or better said: I'm worried that the very same people would be the
> ones that get involved in the process over and over again.

Indeed, the idea is to have a turn-over, which is partially spelt out in
the proposal. If everybody takes part twice and there is a renewal of
half of the people every time, we would avoid that people get burnt out
and still pass on experiences with the process.

> That's why I'm trying to find a way to make everybody get involved in the
> process in their everyday work, so the actual release process is not that
> hard and makes it more likely to people to join.

Good point, which maybe should not be a part of this GCD, but a subject
of further thought: How can we make our life easier? How can we improve
the quality of Guix? When Ludovic added the deprecation policy to the
manual, I suppose that was something he had in mind. Similarly it is the
goal of the Codeberg migration.

> I like the GCD, I think it's thoughtful and well organized, but it might
> lack some of that: let's see how it went and try to make it lighter and
> lighter for the future.

The GCD contains step 14: "Release retrospective". That covers your
point, in my opinion.

But more fundamentally, I think it is not realistic to end up with a
fully automatic procedure. In the end Guix is a social endeavour (lots
of people working together towards a common goal), and I think we need
social processes to reach our goals. For instance, when merging team
branches, we somehow need to negotiate the order; individual teams will
look at their branches and try to advance them, but sometimes it may be
better to let another branch go to the front. Similarly for a release,
decisions will have to be made. Packages may have to be dropped, the
latest release of desktop environment X which is almost, but not quite,
ready may have to be excluded, and so on. Having a team to coordinate
this, and also invested to take unpopular decisions, is necessary in my
opinion.

Also I think we need a period of manual testing. As Vagrant said,
sometimes packaging for Debian, for instance, reveals problems that we
had not seen before. Or asking people to try an installation on an
exotic architecture.

Andreas