Hi Chris, Christopher Baines <m...@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’.