Re: Bringing substitutes from the Guix Build Coordinator to users

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]


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

> Christopher Baines <mail@cbaines.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
>> As people are going to Cuirass to look at the build status for packages,
>> system tests and various branches, the problem is similar to that of
>> substitutes. It doesn't matter if the Guix Build Coordinator seems to do
>> some things better, when the question comes up about whether something
>> has built yet, or whether a branch is ready to merge, Cuirass on
>> ci.guix.gnu.org is where people are going, and that seems unlikely to
>> change (at least less likely than the setup for providing substitutes).
>>
>> The Guix Data Service in the center, making it easier to do various
>> things by providing the data, this was the idea when it started, but the
>> reality recently is that strategy hasn't been paying off.
>
> The Data Service provides a wealth of information that’s underused!
>
> I think addressing the interface issue (be it web UI or JSON + CLI) is
> high priority so we can all start taking advantage of the Data Service.
> The current interface is generic enough that it allows you to see
> everything, from lint warnings to version changes to reproducitility
> rates.
>
> We could have interfaces that answer very specific needs:
>
>   • Which packages are broken on x86_64?

While the Guix Data Service can sort of do this (if it has builds data),
I think Cuirass has a page for that now, there's not a single URL for
the latest evaulation, but assuming you click on the latest one, this
page list the failed builds for x86_64:

  https://ci.guix.gnu.org/eval/30959/dashboard

>   • How does branch X compare to branch Y in terms of build failures?
>
>   • Which packages are not reproducible?
>
>   • Which packages are “flaky”?
>
> I know all this information is already available from the web UI, but
> because it’s generic, it can be hard to find out how to answer very
> concrete issues like this.
>
> A QA entry point like you proposed in the thread you mentioned¹ could
> certainly help.  A reproducibility entry point would be nice too.  A
> package browser for guix.gnu.org like the one Danjela worked on would be
> great too, possibly with version browsing facilities.  And Guix Weekly
> News!  And the security tracker!  :-)
>
> ¹ https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00096.html
>
> It seems to me that all that hard work is already done and what I
> describe above are rather low-hanging fruits.
>
> Taking Conway’s law into account, we may find it easier to recruit if as
> much as possible takes place here, things get deployed behind
> *.guix.gnu.org, and relevant bits are made part of Guix proper.  And
> also, we must regularly advertise progress; one blog post in all of the
> Guix Data Service’s lifetime is not enough.  :-)
>
> Thoughts?

This doesn't really relate to the subject of substitutes.

Some of the things you mention do relate to work I'm trying to progress
though. I'm still working on automated patch (plus branch) testing, and
I think having a simple overview of patch+branch states is hopefully
something that I'll get to at some point.

On the subject of the patch testing stuff, that isn't under
.guix.gnu.org and I haven't written a blog post yet. I can't see Cuirass
starting to test patches, but then I wouldn't have predicted it would be
managing builds across multiple machines. Maybe there are some risks
with the patch testing work that I haven't done enough/the right stuff
to mitigate.

I've also got too many things in progress at the moment, with the
combination of work on substitutes (I hope to implement things set out
in [1] some point soon), Outreachy, and the security related work that
I'm trying to start, I need to "finish" some things before starting new
ones or going back to unfinished things.

1: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00104.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]