Re: On the quest for a new release model

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

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

That's a good idea, and that's the direction I think we agree we should
go (automate all things -- leaving the human part to just a bit of
communication).

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

Sounds like we'd need at least at new switch to enable grafts in the job
spec?  Could we have a job spec running 'make release' ?  Perhaps run
once a day (nightly releases).

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

Dropping it seems to be the most efficient way going forward, in my
opinion.  It appears not much used, if judging per the large number of
broken packages and the little activity going toward fixing them on that
architecture.  If even very well resourced distributions are leaving it
behind [0] (that was 2 years ago), perhaps the time has come for us to
follow suite and focus our efforts where it matters most.

[0]  https://fedoraproject.org/wiki/Changes/RetireARMv7

-- 
Thanks,
Maxim