[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christopher Baines
Subject: Re: Project direction with testing changes (branches and patches)
Date: Wed, 11 Aug 2021 23:27:14 +0100
User-agent: mu4e 1.4.15; emacs 27.2

Ludovic Courtès <> writes:

> Hi Chris,
> Christopher Baines <> 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:
>> 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.

I know it tracks some derivations against a revision, but it has only
been tracking all of the derivations associated with each revision since
this change [1].


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

I don't perceive this as bitterness, just pragmatism.

I think I have an answer now as to whether there's consensus on making
use of the Guix Data Service and Guix Build Coordinator for testing
changes. Knowing there's some objections is useful when considering the
risk and managing my own expectations.

I still personally think that the general direction this work is going
is a good one. There's still some areas of uncertianty, but there's
definitely some stuff that can be done to move forward and more
discussion that can be had.

Thanks for your suggestions on next steps, I still need to get my own
thoughts in order. As you alluded to, I do like to have a plan in mind.



Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]