Subject: Re: GCD005: Regular and efficient releases

From: Greg Hogan <[email-masked]>
Date: Tue, 13 May 2025 11:03:02 -0400

On Tue, May 13, 2025 at 9:11 AM Andreas Enge <[email-masked]> wrote:
>
> Hello Greg,
>
> I am having some trouble following your argumentation; in the beginning
> of your different postings I got the impression that you did not see
> a need for releases, since one could always do a "guix pull". But then
> you end with:

Hi Andreas,

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 build artifacts plus every package in working order
then I find that to be a Herculean task. There is of course tremendous
value in this because on every contribution the developer must
investigate whether build failures are newly caused or preexisting (or
ephemeral or system dependent). I fully support this attempt, I just
think we should first attempt to get every package in working order
before codifying this annual process in a GCD.

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

Can we not similarly automate creation of the ISO and QCOW2 artifacts?
Then, as you note, these need to be manually tested and blessed as a
release. But I don't see why the ancillary packages need to be in
working order to cut a new release.

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

It would be nice to make your teams coordinator position official.
Considering the number of ideas for improving the teams workflow, we
are probably due for a GCD. And I think that is the right process, to
have the GCD deliberate the lessons learned rather than speculate
beforehand.

> Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan:
> > I think we should release more often (multiple times per year)
>
> So I am definitely not getting your point! With the goal of moving forward,
> could you try to reformulate your ideas? Are there concrete points we could
> improve in the GCD, or do you think it should simply be dropped as not
> relevant to the real problem? If we missed it, what is the real problem?

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

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"?

Greg