Re: Project direction with testing changes (branches and patches)

[Ludovic Courtès]

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> I was thinking of using Cuirass for building derivations when testing
> patches, but I gave up on that approach back in 2019 after trying to use
> it (I discussed trying to use it here [1]).
>
> 1: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html
>
> I was specifically thinking about testing patches when I initially
> designed both the Guix Data Service and Guix Build Coordinator. For me
> at least, the focus has been on this direction for the last ~3 years.
>
> I realise that Cuirass now has some of the functionality that the Guix
> Data Service was written to provide, like tracking all
> packages/derivations in each revision. But from my perspective, Cuirass
> still lacks key things like being able to compare two revisions and
> tracking lint warnings.

Cuirass has always had to track packages/derivations in each revision;
it’s been this way from day 1 when it started more or less as a
revisited Hydra, which did exactly this.

The Guix Data Service provides info not available elsewhere though, and
that’s why we need to take advantage of it.

> There's also things like testing derivations on different hardware,
> regularly testing fixed output derivations and automatically retrying
> failed builds that I think the Guix Build Coordinator is better setup to
> do compared to Cuirass.
>
> But this feedback is why I started this thread. I don't see the same
> option as was found for improving substitutes by setting up a new
> substitute server using the Guix Data Service and the Guix Build
> Coordinator. There's a much stronger need to have one approach as a
> project for testing changes, and if using the Guix Data Service and Guix
> Build Coordinator isn't looking like a convincing option at this point,
> that's better to know now, compared to later when more time and effort
> has been put in.

I can sympathize with the bitter feeling.  I do think though that we
must work collectively; to me it’d be a problem if misplaced competition
were to prevent us from moving forward.

Several concrete incremental steps were proposed in this thread and
earlier.  Instead of trying to provide a definite answer as to whether
the grand plan you propose is a convincing option at this point, I’d
like us to collect the low-hanging fruits, in an opportunistic way.  :-)

Several easy hacks have been proposed in this thread and before: custom
web/CLI views for the Data Service, Cuirass APIs to spin up specs on the
fly, Data Service integration in Mumi/Gitile, Cuirass notifications sent
to the Data Service, etc.  None of these is impressive in itself, but
each of these can be a step making our hacker lives better, IMO.

WDYT?

Thanks,
Ludo’.