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
