Subject: Re: GCD005: Regular and efficient releases

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

Hi Greg,

thanks for clarifying, this is indeed very helpful.

Am Tue, May 13, 2025 at 11:03:02AM -0400 schrieb Greg Hogan:
> There may be some confusion in terms. The GCD states "there are
> currently over 30,000 packages in the archive" and "Guix would still
> make all packages and services part of a release (the entire
> archive)". And when I look up the definition of archive I see
> references to "historical documents" and "preservation".
> (...)
> If a release is simply build artifacts, then we are already automating
> part of this process. I count 10 builds of the binary release across
> March and April:
>   https://ci.guix.gnu.org/search?query=guix-binary

I think the release proposal tries to reach some middle ground between
these. There is supposed to be a set of "important" packages which
should build (or be removed, so that the users get what the description
says), the "package sets". These are not yet really defined, and doing
so is given as a task for the release team (no 05, "package set
finalisation"). They would block a release.

The remaining close to 30000 ones will be shipped ("released") whether
they build or not; it is clear we will never reach a 100% perfect
distribution (and I think it is a task for the teams to more
aggressively remove packages in their realm that do not work, which
should not be postponed and left to the release team).

I agree that the GCD is a bit ambiguous about this and in particular the
removal procedure; it mentions the "deprecation policy", but this takes
a month in itself, so is probably not compatible with the tight release
schedule.

So as a practical example, I suppose we will define a desktop
environment package set; gnome will certainly be a part of it, and maybe
something else (xfce? sway?), but probably neiter lxqt nor kde. Then if
lxqt does not build, the release team would not care. If gnome does not
build, the release team would push the gnome team to repair it. In
theory gnome could be removed from the release, but I find it difficult
to imagine, although it would be possible as a last resort, together
with an entry in the release announcement. More likely, we will all push
very hard to get gnome in. But probably renounce at a last minute
transition to a newer gnome version.

> Does this clarify? I see this proposal as trying to 1) manually fix 2)
> all of Guix's problems in 3) a shortened time window, shrinking what
> we are unable to maintain in 12 months into a few weeks (the only
> thing missing is closing all issues during the release cycle).

Definitely not all problems, but we hope at least some!

> And maybe it works! Maybe the 10x and 100x contributors, including the
> sponsors of this GCD, will happily fix everything and make this
> happen. I can accept that. But why not just do that already? Are the
> core developers not empowered? Too deferential? What improvements does
> this GCD offer other than a process to "encourage and excite"?

This is the hope, that "encourage and excite" will make the difference 
during a release cycle. Clearly we cannot all be excited all the time :)

Andreas