Re: Medium-term road map

[Christopher Baines <mail@cbaines.net>]

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


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

> We released 1.1.0, but what’s coming next?  What would you like to see?

Thanks for starting this thread Ludo, I love this kind of thinking :)

> There are many exciting things being developed and great ideas floating
> around.  For myself, I feel like focusing on “consolidating” what we
> have in the coming weeks.  Here are the areas I hope to focus on (and
> embarking as many of you as possible :-)):
>
>   1. Authentication.  I want to finally provide a standardized mechanism
>      to allow channels to be authenticated upon ‘guix pull’.  “make
>      authenticate” was a first milestone, let’s get it done.  See
>      <https://issues.guix.gnu.org/issue/22883>.

Sounds useful!

>   2. Performance.  There are many things we can improve there, first and
>      foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>      compiler terrible time and space requirements, further optimizing
>      core operations like ‘package-derivation’, as well as low-level
>      stuff as described at <https://issues.guix.gnu.org/issue/40626>.

I remember saying that the Guix Data Service times various things, and
that it could time the "Computing derivation" bit, but it doesn't store
that data currently. While the performance is dependent on what else is
going on at the same time, it might be interesting to store the data to
see if there's a trend going forward.

>      Related to that is the question of substitute availability, another
>      major hindrance to usability.  We should address this both in the
>      build farm (reducing the
>      time-to-push-to-time-of-substitute-availability, tracking random
>      build failures), and on the client side (can we provide ways for
>      users to pull to a commit that won’t require them to build
>      everything from source, while not compromising on their security?).

Substitute availability as well as building things is something I've
been interested in recently. With your guidance, I think Bayfront is
working more reliably now, although like Berlin there is a disk space
issue to be worked on.

The Guix Data Service has some awareness of substitute availablility,
but the data is not as up to date as it could be, and there isn't a
great way of looking at it either. I hope to address that over the next
few weeks.

In terms of building things, I'm working on making it possible to use
the "Guix Build Coordinator" thing I've been building [1] to provide
substitues, and I'll hopefully send an email out about that soon.

1: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00323.html

>   3. G-exps.  We should really finish the migration to gexps, as in the
>      ‘wip-build-system-gexp’ branch, and adjust our APIs accordingly.
>
>   4. User interface.  Let’s get our act together with ‘guix shell’ and
>      ‘guix run-script’, and let’s address other annoyances that
>      newcomers keep stumbling upon!
>
> Thoughts?

The other things on my mind are:

Patch submission and review, some information in [2]. I at least want to
do some more work on the Guix Data Service to make the comparisons more
useful for reviewing patches, as well as seeing if I can get the Guix
Build Coordinator to build the affected things, and report back. Then
there are all the issues around submitting packages, like how do I know
if someone is working on this already, or how do I know this hasn't been
updated on core-updates, and how can actually submitting patches be made
easier.

2: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00476.html

More sophisticated policies on accepting substitutes, this means being
able to say things like "I trust substitutes if there signed by all
these keys/entities". While most of the work on reproducible builds has
been on getting things to build reproducibly, Guix could lead the way on
doing the user facing side of this. A majority of the substitutes for
x86_64-linux match between Bayfront and Berlin, so we already have a
minimially viable "rebuilder" setup to actually make use of this.

Thanks,

Chris

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