Subject: Re: Bringing substitutes from the Guix Build Coordinator to users

From: Christopher Baines <[email-masked]>
Date: Tue, 18 May 2021 23:29:52 +0100

Ludovic Courtès <[email-masked]> writes:

> Hello!
>
> Christopher Baines <[email-masked]> skribis:
>
>> Christopher Baines <[email-masked]> writes:
>>
>>> Is there still a path to bring some of these benefits to users, and if
>>> so, what things need doing?
>
> [...]
>
>> Obviously just having the substitutes doesn't magically get them to
>> users, so I've started looking in to the changes to start making that
>> happen. Adding the signing key and changing the defaults in a few places
>> seems like a good step forward [1].
>>
>> 1: https://issues.guix.gnu.org/48435
>>
>> I want to push on with this within the next couple of weeks, mostly so I
>> can shift focus to Outreachy and the security related tooling work, but
>> also because I still think this will be a good step forward in terms of
>> substitute availability for users. It's been over a year now since
>> implementation started, so it would be good to actually make a positive
>> difference.
>
> I’m fine with distributing an extra signing key alongside that of
> ci.guix.gnu.org.

Great.

> I’m unsure about having two substitute URLs by default since it adds a
> bit of overhead, though that overhead is only upon cache misses (I have
> that setup on my laptop actually).

All of this work has been built on the assumption that it's possible to
do better in providing substitutes, and anecdotally from the data I've
seen over the last year, that should be possible, even with the limited
hardware (compared to ci.guix.gnu.org) connected to bayfront.

So yes, that's a valid concern, but if all the addition of bayfront does
is make users wait a little longer because of cache misses, it's a sign
that the whole endeavour is not working out.

> It’s also a one-way change: people are likely to keep the defaults
> “forever”.  So we can’t just “experiment” and change our mind later.
> That means we should at least have a DNS entry that’s not tied to a
> particular machine, like ci2.guix.gnu.org or whatever.

That sounds sensible. On the specific name, given this is just about
substitutes, and at least in my opinion has nothing to do with
continuous integration, maybe picking just another word would avoid
thinking too much, it could be bordeaux, or hippo, or anything
really. As you say, stability and not being tied to a particular machine
is the important thing.