Re: Golang go-updates feature branch?

[Leo Famulari <leo@famulari.name>]

On Thu, Feb 16, 2023 at 09:05:42PM +0100, Josselin Poiret wrote:
> What's the reason behind branch-specific manifests? I'd imagine we'd
> want to test that Guix as a whole still works, even when upgrading just
> specific parts.  Otherwise, I guess this shouldn't qualify for a blog
> post, maybe the cookbook but I'd even just add this as a comment at the
> very top of `build-aux/cuirass/evaluate.scm`, since that's where people
> will go looking for it.  If it does end up becoming widespread, perhaps
> a section of the manual/cookbook dedicated to how feature branches work
> could be a nice home for these bits of info.

Well, now that you ask, I guess there's not a good reason to use
manifests here.

After creating the kernel-updates CI job based on a manifest, I figured
we'd use the same pattern for this, but I agree it's a bit clunky.

On the other hand, Cuirass does tend to obscure the salient information
when testing a branch that doesn't rebuild the world (i.e.
core-updates).

For example, for kernel updates, I want to know 1) if the kernel
packages built and 2) do the system tests still pass? If I simply asked
Cuirass to build everything on the kernel-updates branch, it might end
up showing me the result of a bunch of unrelated package builds just
because they happened to be selected as part of this jobset rather than
'master', due to (un)lucky timing. Does that make sense?

Zooming out, our tooling still has a very long way to go. There are so
many crucial features of Nix's Hydra (which we used previously) that we
are still missing from Cuirass, and it's made it *much* more difficult
to efficiently and carefully perform big updates to Guix, even though
the build farm hardware is more capable than when we used to run Hydra.
This was all so much easier with Hydra.

Sorry for the rambling response that went off-topic. This has been on my
mind.