Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari <leo@famulari.name>]

On Tue, Mar 16, 2021 at 10:18:08PM +0100, Vincent Legoll wrote:
> I think we really should be shortening our releases cycles (core-updates,
> staging merges), because piling upon those branches for too long increase
> the disruption in a way that is probably more exponential than linear.

For most grafted packages, it's always been the goal to regularly
ungraft, maybe within a few weeks. However, we have never actually had
the build farm capacity to do this for all the platforms that we
support.

Currently, I think we have the capacity for x86_64 and i686 (they use
the same build machines), but not for anything else.

Some packages that qualify for grafts can usually be updated without any
breakage, like OpenSSL.

But other packages, like glibc, cannot be updated in isolation. They
require extensive validation and updates of other packages, sometimes
even requiring patching. It's not just a matter of compute capacity.

This distinction actually highlights what is meant by "core" in Guix.
Due to lack of build farm capacity, core-updates has come to encompass
any changes that causes more than 1800 rebuilds. But, "core" is actually
defined explicitly in Guix [0], and it's literally the core of the
package graph and the GNU system. As the number of packages in Guix has
grown, more and more non-core packages have come to fit in core-updates.
Maybe there is room for improvment here, but I don't know what it is.

I do think we should strive to ungraft things more quickly, maybe after
clarifying the support status of the armhf, aarch64, and ppc64le
platforms.

[0] Check the core-package? procedure in guix/scripts/refresh.scm