[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Medium-term road map
From: |
Ludovic Courtès |
Subject: |
Re: Medium-term road map |
Date: |
Sun, 03 May 2020 22:11:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi!
Christopher Baines <address@hidden> skribis:
> Ludovic Courtès <address@hidden> 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 :)
Though I realize now that I have an email problem that introduces a
significant delay in my response time, and I apologize for it!
>> 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.
Yup!
Performance monitoring in general would be nice, and could have been a
subject for GSoC/Outreachy.
> 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
Would be nice.
> 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.
+1!
Thanks,
Ludo’.