From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Patchwork + automated checking and testing of patches Date: Thu, 01 Nov 2018 16:22:58 +0100 Message-ID: <87pnvostyl.fsf@gnu.org> References: <87h8h29z2j.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIEoJ-0005y4-AV for guix-devel@gnu.org; Thu, 01 Nov 2018 11:23:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIEoI-0004Bl-1S for guix-devel@gnu.org; Thu, 01 Nov 2018 11:23:03 -0400 In-Reply-To: <87h8h29z2j.fsf@cbaines.net> (Christopher Baines's message of "Wed, 31 Oct 2018 10:43:00 +0000") 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: Christopher Baines Cc: Guix-devel Hello! Christopher Baines skribis: > I haven't used Patchwork [1], but it has been tried previously with Guix > [2][3]. It also seems to be a step forward in terms of taking what's > sent to the mailing list and organising it. > > 1: http://jk.ozlabs.org/projects/patchwork/ > 2: https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00056.html > 3: https://patchwork.sourceware.org/project/guix/list/ > > 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]. > > 4: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D33185 > 5: https://patchwork.cbaines.net/ > 6: https://patchwork.cbaines.net/project/guix-patches/list/?state=3D3 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? > 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 (guix = inferior)), things to apply patches, etc. We don=E2=80=99t want to reimplement Patchwork, GitLab, etc. so anything th= at 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. Thanks! Ludo=E2=80=99.