Re: On the quest for a new release model

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Greg Hogan <code@greghogan.com> writes:
>
>> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh <suhailsingh247@gmail.com> 
>> wrote:
>>>
>>> Suhail Singh <suhailsingh247@gmail.com> writes:
>>>
>>> > The issue, as I see it, is the time commitment required from the
>>> > release-team.
>>>
>>> Correction, the issues (IMO) are (in no particular order):
>>> 1. the timespan (several weeks)
>>> 2. uncertainty around total effort
>>> 3. amount of manual effort involved
>>>
>>> It's unclear which of the three above is the rate-limiting-step.

Of course the goal is to keep total individual effort limited, and
having several people involved can make that happen.

What this should primarily involve is keeping track of issues we want to
be fixed by time of release, and making sure that progress is made.  The
“several-week commitment” phrasing is here because to keep track of
things, one should rather avoid walking away and come back two weeks
later; it doesn’t have to be a lot of work though, it’s mostly
coordination.

>> There is also access to hardware. From doc/release.org:
>>
>> "Steps #2 and #3 require you to have offloading set up so you can
>> build for all the supported architectures.  For instance, if you’re
>> running this on an x86_64 machine, you should have ~armhf-linux~,
>> ~aarch64-linux~ and ~powerpc64le-linux~ machines in your
>> =/etc/guix/machines.scm=. Transparent emulation via QEMU has shown
>> limits (such as causing test suite failures); real hardware is a
>> must."

I agree that’s a problem.

> Indeed, at least for the person running 'make release'.

Right.  We could perhaps avoid that by ensuring ci.guix builds all the
relevant artifacts.  It’s already set up to do that anyway, but the
workflow needs to be reworked so that almost everything happens on
ci.guix and ‘make release’ can simply fetch substitutes for the
artifacts.

What makes it more difficult is the two-step process in ‘make release’
(where it first updates the ‘guix’ package and then builds the artifacts
and ISOs) and (now that I think about it) the fact that the guix-binary
tarballs built on ci.guix have grafts disabled, I think.

> I think the Guix binary release can be built from aarch64; we've never
> had true armhf offload machines, as far as I know.

As far as ci.guix is concerned, we’re too low on Arm build power to
build for both aarch64 and armhf, so that too is a problem.  In
practice, at release time we could tweak scheduling for aarch64-linux
builds, but we’d still need to prepare for armhf-linux long before… or
just drop it.

Ludo’.