unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org, 48435@debbugs.gnu.org
Subject: Re: Bringing substitutes from the Guix Build Coordinator to users
Date: Tue, 18 May 2021 23:29:52 +0100	[thread overview]
Message-ID: <87im3fbrq7.fsf@cbaines.net> (raw)
In-Reply-To: <87wnrv68h7.fsf@gnu.org>

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


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

> Hello!
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Christopher Baines <mail@cbaines.net> 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.

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

  reply	other threads:[~2021-05-18 22:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01 18:56 Bringing substitutes from the Guix Build Coordinator to users Christopher Baines
2021-05-02 21:51 ` Ludovic Courtès
2021-05-03 10:30   ` Christopher Baines
2021-05-04  8:27     ` Ludovic Courtès
2021-05-04 19:22       ` Christopher Baines
2021-05-11 20:18         ` Ludovic Courtès
2021-05-04 18:38 ` Andreas Enge
2021-05-04 19:29   ` Christopher Baines
2021-05-12 22:58     ` Christopher Baines
2021-05-15 16:38       ` Ludovic Courtès
2021-05-15 17:24         ` Christopher Baines
2021-05-17 20:28           ` Ludovic Courtès
2021-05-18  8:26             ` Christopher Baines
2021-05-06 16:26   ` Ludovic Courtès
2021-05-18 19:45 ` [bug#48435] " Christopher Baines
2021-05-18 21:24   ` Ludovic Courtès
2021-05-18 22:29     ` Christopher Baines [this message]
2021-05-19  6:54       ` Mathieu Othacehe
2021-05-19  7:57         ` Christopher Baines
2021-06-07 14:53   ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87im3fbrq7.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=48435@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).