Subject: Re: GCD005: Regular and efficient releases

From: Ekaitz Zarraga <[email-masked]>
Date: Sat, 10 May 2025 13:04:18 +0200

On 2025-05-10 11:15, Andreas Enge wrote:
> Hello Ekaitz,
> 
> Am Sat, May 10, 2025 at 12:59:32AM +0200 schrieb Ekaitz Zarraga:
>> Steve, you asked for my thoughts, and here they are: probably not what you
>> expected (:
> 
> thanks for your contribution, which brings up some interesting thoughts;
> they sound provocative, but I find it useful to step out of the box and
> ask the question: "do we need releases at all?". (Which goes a little
> bit beyond what you actually suggested.) And one possible outcome of our
> GCDs is that in the end, we decide the problem they try to solve is not
> really a problem, but the GCD process has allowed us to come to this
> joint conclusion and thus to move forward as a project.
> 
> Indeed if we have lived without releases for a long time, it is because
> the rolling model makes them less pressing: As long as one can install
> any Guix version at all, one can do a "guix pull" afterwards and be
> up to date.
> 
> An automatic release process would solve some of the problems that
> motivated this proposal: Debian could package the latest release no matter
> how it was obtained; "guix pull" would start from a point closer to the
> current master branch; and so on.
> 
> What is added by a manual release process, in my opinion, is quality
> control. While the master branch is supposed to be in perfect shape all
> the time, it actually is not:
> - Sometimes there are breaking changes with problems only discovered
>    afterwards. For instance, the move to a non-privileged daemon caused
>    problems which are being solved now. Hopefully such a breaking change
>    would not make it into a release due to the freezing period.
> - Ungrafting is a big issue that would be done during a release, and
>    the past has shown that it cannot be done completely automatically
>    (sometimes things break when ungrafting). Currently on a high-speed
>    Internet line it may take more time to graft the packages than to
>    download them.
> - Recently when updating a package and checking which dependent packages
>    it would break, I noticed that several of them (!) had not been built
>    for years (!), and nobody had taken the time to fix or remove them.
>    Filing removal requests resulted in them being fixed or removed, and
>    a better quality of Guix (in a very small niche) and easier
>    maintenance: now doing a "guix build -P 1 this-package" actually tells
>    whether this-package update breaks anything or not.
> 
> These are things we *could* do any time, but which are probably not much
> fun, and so they are not done. Crafting manual releases means we *must*
> address such problems and face our quality issues.
> 
> This could also be a first step towards an additional stable branch,
> which people have called for, on which security updates and (to be
> discussed) limited package updates could be made. This is outside the
> scope of this GCD, but I think that quality based releases on a certain
> schedule are a prerequisite.
> 
> Clearly we could not (or would not like to) do security updates on a
> branch as old as our 1.4 release; and it would also not work in your
> alternative model in which, if I understand it correctly, releases would
> be made essentially by putting a 3 digit version number periodically on
> git commits, which would essentially be a purely rolling model.
> 
> Andreas
> 

So, there it goes!

You answered my question really clearly: We don't actually *need* to 
make the releases manually, but we need the stability that process gives 
us, specially for ungrafting.

My proposal was the most radical I could think about: just don't have a 
release process. Or as you put it "put a three digit version number in 
git commits". But the idea was to think about the grey, adding some 
black to the white the GCD proposed.

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.

The question now is how do we achieve that. You point the goal of the 
release process is the quality control. Now I wonder if there's any way 
to relief the release of some of that weight (or all of it), being a 
little bit more cautious during the rest of the year.

I know that makes every day less fun, but 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.

And this takes me to the actual specifics of the GCD:

I think one of the reasons we don't have a release for that long time is 
the lack of people taking care of it. The GCD has a plan about it, but 
it relies on having people involved in the process.

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.

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. The way I have to 
think about it is to imagine a future when releases can be automatic, 
and think about what is preventing us from having that now.

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.

Maybe adding that is just a matter of publishing some 
blogpost/survey/... after the first release is done using this process 
where people share ideas on how we could implement improvements in our 
everyday lives. After that, I suppose more GCDs would be proposed: a 
long-lived stable branch, a full-automation proposal, better CI/CD 
process, proper package testing... Whatever that is so we keep the wheel 
rolling.

There's already some of that in the GCD: package sets are a very nice 
way to make sure we are specially careful with some packages, and that's 
something we can do every single day.

Does this make more sense now?

Thanks Andreas for your response,
Ekaitz