From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2N2/G7Khy19hSAAA0tVLHw (envelope-from ) for ; Sat, 05 Dec 2020 15:05:22 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QBNyF7Khy18xJAAAbx9fmQ (envelope-from ) for ; Sat, 05 Dec 2020 15:05:22 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C499894043B for ; Sat, 5 Dec 2020 15:05:21 +0000 (UTC) Received: from localhost ([::1]:60386 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klZ7g-0005o0-GP for larch@yhetil.org; Sat, 05 Dec 2020 10:05:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klZ7O-0005ly-Jm for guix-devel@gnu.org; Sat, 05 Dec 2020 10:05:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46819) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klZ7O-0001IM-5m; Sat, 05 Dec 2020 10:05:02 -0500 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=58516 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1klZ7J-0004kW-Kf; Sat, 05 Dec 2020 10:04:58 -0500 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Christopher Baines Subject: Re: More thoughts on Patchwork and Guix patch review/quality assurance References: <87v9dos547.fsf@cbaines.net> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Frimaire an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Sat, 05 Dec 2020 16:04:55 +0100 In-Reply-To: <87v9dos547.fsf@cbaines.net> (Christopher Baines's message of "Sun, 29 Nov 2020 12:46:16 +0000") Message-ID: <87tut05m5k.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.80 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: C499894043B X-Spam-Score: -2.80 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: ykjO5QA2tXj9 Hi Chris! Christopher Baines skribis: > If you're interested in using this to review patches, the place to start > is Patchwork, so visit: > > https://patchwork.cbaines.net/ > > If you want an account, please email me. Unfortunately I had to disable > registration due to spam. > > When you click through to a patch, the thing to look at is the > checks. These should link you to the relevant bug, Git branch and Guix > Data Service comparison. For the Guix Data Service comparison, the > things to note are the lint warnings and then clicking through to the > "Compare package derivations" page. Very nice! This is useful info when reviewing, and it=E2=80=99s much harde= r to get this at a glance locally. > ### Use Patchwork, rather than Debbugs to track patches > > So this has been a thing for 4 years now (see [2] for some graphs). I > think I was there in the bar in Brussels when it was discussed. > > 2: https://debbugs.gnu.org/rrd/guix-patches.html I remember that night in Brussels, it=E2=80=99s been a while! :-) > The main disadvantage I see of using Debbugs is that you have to get a > bug number before you can Git send-email, in the case where you're > sending multiple patches. > > The main advantage I get from Debbugs is that searching via the bug > number is really useful. > > I'm unsure, I think Debbugs was introduced to help keep track of > patches, and avoid them getting forgotten in guix-devel. Patchwork will > do this too, but maybe Debbugs is providing more value than the cost of > multi-patch series being slightly more difficult to submit? To me, the main advantages of Debbugs are: 1. the Emacs interface (I use it a lot as a reviewer, no need to open a browser); 2. the clean web interface at , which I find less intimidating, less cluttered, and hopefully more familiar than that of Patchwork; it also has a useful search interface now; 3. Having numbers and short URLs to reference issues. Now, Patchwork =E2=80=9Cchecks=E2=80=9D and how you use them are great; sim= plifying multi-patch submissions is great too. If Mumi had hooks that could be used to run and display those checks, I=E2=80=99d be super happy. But I don=E2=80=99t know whether it=E2=80=99s = reasonable, nor whether that=E2=80=99s something others would also like. :-) All this could be complemented by CLIs to =E2=80=9Cthe official Guix review services=E2=80=9D (Patchwork, Mumi, Data Service, etc.). You could run: guix review 1234 and it=E2=80=99d fetch the patch(es), apply them, and/or display a status summary based on data published by Patchwork & co. It=E2=80=99s probably n= ot that much work if those services have HTTP APIs, and it could facilitate adoption. > ### Scheduled and regular collaboration on IRC to review patches > > When I can make some time, I'll try this out, but if anyone has some > time they can set aside, please go ahead! Yes! A weekly meeting where committers and submitters are around and focusing on getting patches merged would be great! > ### Help users with the submitting part of submitting patches > > Using git send-email works well with Patchwork at least, and it's fine > with Debbugs if you've got a single patch, but a little more time > consuming if you're got more than one patch. > > Attaching a single patch file to an email works OK I think, however > attaching multiple patch files to the same email confuses git am and > Patchwork I believe. > > I think other approaches like copying the patch in to the body of an > email, or just copying the output of git diff in to an email are very > brittle and can make it more time consuming to try and recover or > recreate the commit(s). > > Having the emails for patches is useful for reviewing, but maybe there's > a way users could push a branch somewhere and then have some service do > the git send-email thing on their behalf? Yes, that would be nice. To me that=E2=80=99s less important than getting = the checks you implemented actually used, though. > ### Notify interested people about patches > > This is something I've been thinking about more generally, supporting > email subscriptions for things like a new version of a package being > available, or the package failing to build on > master/staging/core-updates. > > But specifically for patches, maybe there could be a way of subscribing > so that you're emailed when a patch series upgrades a package you're > subscribed to, or breaks a package you're subscribed to. > > This could help get more people involved in reviewing patches, by making > it easier for the interested people to find out about patches they're > interested in. +1! > ### Helping people who aren't committers review patches > > I don't know how much of this happens, but it might be something to > better support? > > Better supporting it could mean documenting how to get things that have > passed review merged in, like emailing a list of committers when a patch > series is ready to merge. Agreed. Non-committers do review occasionally and I find it very useful. > ### Making automated testing more rigorous > > So, providing the patches can be automatically processed and apply > successfully, I'm currently building packages for x86_64-linux and > i686-linux. > > There are more things that could be built if I amend the relevant > script: > > - System tests (maybe just x86_64-linux is relevant? > > - Cross-compiled packages (the Guix Data Service currently only > generates these for x86_64-linux) ci.guix.gnu.org is doing that and (gnu ci) as well as etc/system-tests.scm and etc/release-manifest.scm formalize it. > There are also some things that would require more work/hardware: > > - Building packages for architectures other than > x86_64-linux/i668-linux. > > - I have some ideas on getting the Guix Build Coordinator agent > running in a childhurd, some general substitute availability would > also be good for getting this to work Note that GNU/Hurd currently uses out-of-chroot builds; IMO that part needs to be addressed (see ). > - Building packages on a range of hardware with a range of > resources/configurations. This is kind of a better version of just > building a package multiple times. It would help spot odd failures > earlier, and give valuable data about the reproducibility of the > build outputs. > > - Single core vs many cores > > - Not much RAM vs plenty of RAM > > - Different filesystems (btrfs, ext4, ...) > > - Different Linux-libre versions > > - Different system times (2025, 2101, ...)=20 > > - Maybe building on other OS's (Debian, ...) > > These things require hardware availability and/or being able to > control resources for a single build through the guix-daemon. It also > requires a way in the Guix Build Coordinator to specify that you want > builds to happen in this way, so build a single derivation many > times, in each of these environments. Some of these tests could be done by offloading to =E2=80=9Cchildguix=E2=80= =9D VMs or by creating derviations that build derivations in VM. Thanks! Ludo=E2=80=99.