From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Patchwork + the Guix Data Service for assisting with patch review Date: Mon, 30 Mar 2020 22:10:51 +0100 Message-ID: <87d08tsg4k.fsf@cbaines.net> 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]:41426) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJ1gU-0003jD-AD for guix-devel@gnu.org; Mon, 30 Mar 2020 17:11:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJ1gR-0006zZ-Ue for guix-devel@gnu.org; Mon, 30 Mar 2020 17:11:02 -0400 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:37455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJ1gR-0006yY-Nx for guix-devel@gnu.org; Mon, 30 Mar 2020 17:10:59 -0400 Received: from localhost (unknown [46.237.161.230]) by mira.cbaines.net (Postfix) with ESMTPSA id 48B9827BBE1 for ; Mon, 30 Mar 2020 22:10:57 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 112e4f8a for ; Mon, 30 Mar 2020 21:10:54 +0000 (UTC) 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 Hey, I sent out an email [1] yesterday on data.guix.gnu.org and the Guix Data Service software that runs there, but I focused that email around data.guix.gnu.org, this email relates in some way to the first application of the Guix Data Service, which was the prototype I set up for automating parts of reviewing Guix patches. 1: https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00268.html This email is in four rough parts, some rambling, then an update on the "Current Status" of the patch review tooling I've been trying to setup, then a description of "How you can use Patchwork for reviewing patches", then a small comment on "Next steps". All the way back at the end of October 2018, I sent out an email about Patchwork [2], followed by one about the Guix Data Service in February of 2019 [3] and then an email [4] in March which described automatically building packages which are affected by patches. 2: https://lists.gnu.org/archive/html/guix-devel/2018-10/msg00638.html 3: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00089.html 4: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html It's a little frightening where all the time has gone! But while I don't think much has changed in terms of automating and assisting with patch review, the Guix Data Service software, and the deployment at data.guix.gnu.org has moved forward a lot. It can load and store data about packages, derivations, git repositories, lint warnings, builds, substitutes and can already make this data available in useful ways. Which brings the subject back to assisting with patch review. Back when I originally tried to setup Patchwork + the Guix Data Service + Cuirass to build packages related to patches, the building packages never really worked, and even if it did, it would have been very difficult to spot things like a patch breaking a package that used to build. Similarly, while Patchwork + the Laminar jobs could help spotting patches that didn't apply, it still couldn't do much to assist people reviewing patches. Now this started to change around August last year, when the Guix Data Service became capable of storing data for some lint warnings (those that don't use the network). This now meant that at least getting data about patches in to the Guix Data Service could tell you what these patches did in terms of lint warnings for a subset of the checkers. Another useful feature of the Guix Data Service that I've been occasionally using when reviewing patches is it's ability to provide substitutes for derivations. As I've got my computer setup to use the guix-patches-data.cbaines.net instance of the Guix Data Service for substitutes, building a derivation that's new or been changed as a result of a patch is as easy as copying the full filename in to a terminal and running guix build with it. Ideally, building derivations that are new or that have been changed would be automated, and I think the Guix Data Service providing substitutes might be able to help with that. ## Current Status I've got the stuff I setup previously somewhat working again, the following parts are in play: - Patchwork: https://patchwork.cbaines.net/project/guix-patches/list/ - getmail is running to listen for emails - Guix Data Service: https://guix-patches-data.cbaines.net - getmail is running to listen for emails - Laminar: https://laminar.cbaines.net/ - Git stuff: https://git.cbaines.net/guix/patches/ - A combination of Gitolite, cgit, python-git-multimail - My personal mailserver: - Used to subscribe Patchwork to guix-patches - Used to subscribe the Guix Data Service to guix-commits, as well as a mailbox on my mailserver which receives emails regarding the patches Git repository Now not all these parts are essential, but I wanted to describe the current state. How this might work for a typical patch series is as follows: - Patches sent by email to guix-patches@gnu.org - getmail for Patchwork receives the emails, passes them to Patchwork - Patchwork attempts to make sense of the emails - A Laminar job (patchwork-test-new) looks for new patch series in Patchwork, sees there's a new series, and starts the patchwork-test-series Laminar job to process them - The patchwork-test-series Laminar job downloads the patch data from Patchwork, and (hopefully!) applies the patches to the Guix Git repository - The resulting branch (series-NNN, where NNN is the Patchwork series number) is pushed to the git.cbaines.net/guix/patches/ Git repository - The patchwork-test-series Laminar job also talks to Patchwork to fill in the "Checks" that provide links to the Git branch and Guix Data Service comparison. - The python-git-multimail hook sends emails regarding the pushed commits - getmail for the Guix Data Service picks up the emails about the commits for the patches on the series-NNN branch - The Guix Data Service begins processing this revision Hopefully this provides some insight. The link between Laminar and the Guix Data Service is now over email, which while a little complicated, does mimic the way the Guix Data Service listens for guix-commits emails, and because getmail can use IMAP IDLE, hopefully it should be reasonably quick. Also, I've added some more Laminar jobs to attempt to keep the patches in Patchwork, and branches in the Git repository under control. There's now a Laminar job (guix-patchwork-accept-patches) that guesses at which Debbugs bug the patches in Patchwork correspond to, and marks the patches as accepted if the Debbugs bug is closed. This isn't perfect, but at least it does help when looking for unprocessed patches in Patchwork. There's also another Laminar job (guix-patches-branch-cleanup) that looks for branches in the Git repository that map to patch series in Patchwork where all the patches are marked as accepted. If this is the case, it deletes the branch from the Git repository, which also removes it's display from the Guix Data Service index page as well. ## How you can use Patchwork for reviewing patches You can look at Patchwork [5] to find out about patches. You can also register with Patchwork, I'm not quite sure if I'll need to then contact me to configure your account, but once it's working, you should be able to change the states of patches in Patchwork and delegate to people. 5: https://patchwork.cbaines.net/project/guix-patches/list/ It should also be possible to get some assistance applying patches, either through the pwclient command line tool that you can use with Patchwork, which is available in the Guix patchwork package. You can also use the commits/branches in the guix/patches Git repository [6]. 6: https://git.cbaines.net/guix/patches/ By looking at an individual patch (like [7]), you should get some links in the Checks section of the page to the Guix Data Service (View comparison), which will hopefully show you at least about lint warnings as well as changes to packages and derivations. 7: https://patchwork.cbaines.net/patch/20898/ By adding the public key available at [8] to your ACL, and by adding https://guix-patches-data.cbaines.net as a substitute URL, you should be able to download substitutes for derivations and build them. For example: guix build --substitute-urls=https://guix-patches-data.cbaines.net /gnu/store/ada55cgkllh38ldr7ipr8xfdsb4ibh06-r-oenb-0.0.1.drv 8: https://guix-patches-data.cbaines.net/substitutes So there's a few ways in which you might be able to use some of this to assist you when reviewing patches. ## Next steps So in my mind, the key results around this area are somewhat defined. Submitting patches should be quicker and easier, reviewing patches should be less monotonous and automated in part so people can review and improve there own patches, and overall less unintentional breakages should occur while patches should be merged in faster. I'm less certain about what processes and tools to push in terms of how to move towards that though. I'm getting more certain that the Guix Data Service should be useful, but I'm not set at all on using Patchwork or Laminar. While Patchwork really helps making sense of patches submitted through email, it can't make sense of a significant proportion of the guix-patches emails, at least to the point when I've managed to get them to apply. I'm also really hoping that there's a patch submission process with a lower barrier to entry in the future, which I think precludes the submitter having to directly send the email. If there was a patch submission process that didn't involve representing patches inside emails, and then trying to pick them out again, that would remove most of the value of Patchwork. As for Laminar, that's just a way of running scripts with a useful web interface. It's not essential at all. Faced with this uncertainty, my strategy at least is to have more discussion, take small steps forward, and prototype more. I've managed to make some time to work on this area again in the last couple of months, and I'm hoping to do some more in the coming months. Please let me know if you have any comments or questions, and apologies for the exceedingly long email! Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl6CYFtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XdhzQ/7B01kUU0ZdRFNyY8ATQSS/n/yDSafOeGTWNplIcBWUzX6DNLxsODej+FD L409bI3HJEDyEmfvByP0x48YwtQO7qJ+tm9paH3JPfVo8Tiyd2c0GdZynjf3wl5W tGm0taDBGCbw15fESDVJ6fLHq7cSuNIJpqwyneWatK9HjenVzn4YMyj5hi8ZWeyn yjnZSh07YU33NkWcIjIe0V7SUUxLiBhxZXWy/c/Ovdek3Qps+fHVKrbTqa+JVACe s7zVFOipltfErGuXEXJ9WV4c70f4KOwM9kI5nDSb7CktJm+Szvh9qUOMfEBOR1cL FceXsrQVAJYHa+wZtuHRvJf1iFFfrNq1/2m8gRmS15KweRjI3Gs7ixDNP2GGlAo2 eCYsLQ0h2DUDB8JC+/A9GhQ7IibW4LDjpFEaxslmrZrZDiv0Nq/VmhOB6Uu3Qfoh vkvIfQcPSNK6+hjNt+ip6++fbTiUQaf6WUEwMPiVNAkIND2RIY43EdXBMR2Cn18Z mgTKRT6UBWx6S//vLALQLnhDJCiiAvw1uyFFpUwC3HnqqvfiK3OK8IDBMactEW7g zHfeCOvSlH8oeQ7C+mOwsFRMDG8csqEP1ycCj9NbuGl6i1nbwzd3hP5OOoJHZrwd HqayL/3FM+d/aXRLJspf9UaljaVLQ5llO/6XOncRKsqm//gm3GI= =VgTf -----END PGP SIGNATURE----- --=-=-=--