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
