From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: Medium-term road map Date: Sun, 26 Apr 2020 19:14:28 +0100 Message-ID: <877dy2nmgr.fsf@cbaines.net> References: <87mu6zd6tz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35134) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSlna-0007q5-Ms for guix-devel@gnu.org; Sun, 26 Apr 2020 14:14:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSlnY-0006IX-Md for guix-devel@gnu.org; Sun, 26 Apr 2020 14:14:38 -0400 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:49845) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSlnY-0006IA-9C for guix-devel@gnu.org; Sun, 26 Apr 2020 14:14:36 -0400 Received: from localhost (unknown [46.237.175.119]) by mira.cbaines.net (Postfix) with ESMTPSA id 0095E27BBE1 for ; Sun, 26 Apr 2020 19:14:33 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id cd72d136 for ; Sun, 26 Apr 2020 18:14:31 +0000 (UTC) In-reply-to: <87mu6zd6tz.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > We released 1.1.0, but what=E2=80=99s coming next? What would you like t= o 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 =E2=80=9Cconsolidating=E2=80= =9D 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 =E2=80=98guix pull=E2=80= =99. =E2=80=9Cmake > authenticate=E2=80=9D was a first milestone, let=E2=80=99s get it do= ne. See > . Sounds useful! > 2. Performance. There are many things we can improve there, first and > foremost: the =E2=80=9CComputing derivation=E2=80=9D part of =E2=80= =98guix pull=E2=80=99, Guile=E2=80=99s > compiler terrible time and space requirements, further optimizing > core operations like =E2=80=98package-derivation=E2=80=99, as well a= s low-level > stuff as described at . 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=E2=80=99t 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 > =E2=80=98wip-build-system-gexp=E2=80=99 branch, and adjust our APIs = accordingly. > > 4. User interface. Let=E2=80=99s get our act together with =E2=80=98gu= ix shell=E2=80=99 and > =E2=80=98guix run-script=E2=80=99, and let=E2=80=99s address other a= nnoyances 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl6lz4VfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XfhYw/9H4uqUtmu32NXUwOk76P68Yl6vx/sO/QLGpp3hvOAuqqUeQoW7k1UbEbc HfBY3obD1BS9qTbYQRSe4ripchR29gTBCrCwiR3XrvbV2oFbKbL/ys5P3k3rfn34 2SUn6nXAaJpua30nQzHpEjnfi3PTBmi67KUCyiNfWEvvMHMibJeAMrbwY70HiksQ 1iXcrO3f7rO2uQMPSmXN+3YmTrlLWdNd/5crA+sYcpxMtjYoRT/A+ujL5itbcDPC 2K9CYg5fRWgzLuTFARmmn3jZ+mlLif+rF2imCweoXhW0mBCZaLak1Jpe6tCRSobc jL8hGFut3xdjhK99anQ9e2i43tnRh7hIcJBCiJtZLmosvGBxvHhSK3mEQ9V77vNU 3+rIzmvQHoagHh4Fpxo9190bpIJu/99dOZZWTSp9M8W9Hz3qzirzMN7Iyq5wA91K NRrvSLD5w+ulI/2S0z/nD7RV7xCh8/3mibdDv5SOUl/GY6CsbAijWFzL1qtsn6ry ConA8Nk2iRJdlLGqKpgXPOGN1aEEiaAKQ91FrxFLfB8oqO/TLl3QVPOgiYmjrR6E bNgSlLOl7Nq2npDpY+3iNw11+AGFpG2yGZWjGBVYFlSrFbRT/coj6vIp1ZQeV1c3 neJ7PVEufsEmOIgCiiEsLviTi1Ls4YOEylWPnFcetDjGog5hCCY= =Pr6j -----END PGP SIGNATURE----- --=-=-=--