From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: Patchwork + automated checking and testing of patches Date: Thu, 01 Nov 2018 18:55:23 +0000 Message-ID: <871s844oh0.fsf@cbaines.net> References: <87h8h29z2j.fsf@cbaines.net> <87pnvostyl.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:4830:134:3::10]:36226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gII8E-0001HM-Ox for guix-devel@gnu.org; Thu, 01 Nov 2018 14:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gII8A-0001mO-Ok for guix-devel@gnu.org; Thu, 01 Nov 2018 14:55:50 -0400 In-reply-to: <87pnvostyl.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.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Hello! > > Christopher Baines skribis: > >> ... >> >> I've now written a very rough package and service for Patchwork [4], and >> managed to setup a instance here [5]. With the help of an email account >> subscribed to both guix-patches and guix-commits, getmail and a couple >> of scripts, it should also collect new patches sent to guix-patches, and >> mark those that have been merged to the master branch as "Accepted" [6]. >> >> ... > > Back when we tried, it had a couple of shortcomings: > > 1. It would not automatically detect which patches have been merged; > > 2. It would not present patch series correctly. > > From what you write it looks like #1 has been fixed, but the web > interface suggests that #2 isn=E2=80=99t quite fixed yet, is that correct? On the detecting merged patches, that's definately working for some patches though. I don't fully understand what criteria it's using though, as it's comparing the commits that come through to the master branch, and I bet it's possible to confuse it a bit by tweaking patches before pushing them. Regarding patch series, I don't know much about the specifics of this, and I don't know much about Patchwork, but just comparing a few patches on the older version [1], and the newer version [2], it looks like it's better. Take this patch [3], it's part of a series, but you can't tell. However, with this patch [4], you can see the series and related patches towards the top of the page, and also a link to download the whole series as an mbox. How does this look to you? 1: https://patchwork.sourceware.org/project/guix/list/ 2: https://patchwork.cbaines.net/project/guix-patches/list/ 3: https://patchwork.sourceware.org/patch/18558/ 4: https://patchwork.cbaines.net/patch/66/ >> I don't intend to do anything with Jenkins, as I think that wouldn't be >> maintainable, but I think setting up some system to check some of the >> following would be beneficial: >> >> - If a patch series applies to master >> - If ./configure and make run successfully >> - If building a guix package with the patch applied works >> - If running guix lint for all the new/changed packages works >> - If building all the new/changed packages works >> - If running the tests and system tests works > > I think these are all things we=E2=80=99d love to see. > > Apart from item #1, the rest is pretty much Guix-specific. My > suggestion would be to write tooling piecemeal: for example, things that > allow us to determine the set of packages added or upgraded by a patch > (we actually have a bit of that with =E2=80=98guix pull=E2=80=99 and (gui= x inferior)), > things to apply patches, etc. > > We don=E2=80=99t want to reimplement Patchwork, GitLab, etc. so anything = that > can be borrowed from there is welcome. > > What might be nice is integration with Cuirass: if it had an HTTP API to > easily request a branch build, we could easily hook into it; and then, > we can extended its existing HTTP API as we see fit to make it easy to > retrieve info about build statuses and so on. > > All this is easier said than done, but my point is that we should try > and identify easily doable bits so we can incrementally build such a > tool. That all matches up well with what I've been thinking about :) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlvbTBtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9Xd9PBAAsqd5LmVlOQRUgWgXH6dIWxqhp7dW+o9oLLeAiWrlKcycEjWa25q8+SfR l3l98niyxnm5p+prYbq4SpZ9zobN2Xf5YwfhOaP2It1hFyS/UV5xse3cvFaKxdQP OK/IRemqdJ6WsF7soji1SloaH4YTN09xWEvnldsZfuXhnlJgIN/XO22bqh0Q5H1i VnjJrA4J9oSglyR2NB7NTTfmwCykoMzes1jExt1o5bvh1TUB+ID9rq/Qkl4fMqqA C8lryH901sdP4y469qvWALsUga6S58QSuqQAy/xF7IX++xKfY7jzt1W8lpeQangn 8yOjsQlvktiy3PnOccyMX6WqGReOcFgiJkHdKofaezIzi0RpnZs4qi1zEkeHt+5v qNXWyYRaldS3DfJKyONIYQwOH6V+DVtcpCs8gl+EljvySTKZLParrL+sFeoDHckv 4nwr/7q5rAyR7YHx+Q/fwytbCz6IbqNDSezmGWr1xU6U/9UAmSp37O/NWXq/CeB1 wibwxGMRJ5Tn6rcx0kyxMzd4JsodglMSuhckojzt8VL2+pth8yTMhW7xPgUlAcKb o4Jz4hoFXiDvMNcKAQ/6vU18iZS2zQWPhn81/Rc1fF+bpU6MT5N2RYwP1MsXhhND VljJAgI55fcT+4VkSWNbjp6BqEWOC6oK/9fx+kYIw2BVwpemRkI= =4cdt -----END PGP SIGNATURE----- --=-=-=--