unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Guix-devel <guix-devel@gnu.org>
Subject: Patchwork + automated checking and testing of patches
Date: Wed, 31 Oct 2018 10:43:00 +0000	[thread overview]
Message-ID: <87h8h29z2j.fsf@cbaines.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

Hey,

For a while, I've been thinking about ways in which contributing code
changes to Guix can be better, in particular, how things like
automatically checking and testing patches might be beneficial.

Some tooling for doing checks already exists, like guix lint, but you
can't run that on a patch, you need some way of getting from the text
sent to the mailing list to some state in a git repository.

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=33185
5: https://patchwork.cbaines.net/
6: https://patchwork.cbaines.net/project/guix-patches/list/?state=3

What I'm hoping now to do, is to try and use Patchwork to coordinate
automated checking and testing of patch series. I haven't thought much
about this yet, but Patchwork does have something for recording
"checks", demonstrated here [7]. There has also been a talk at FOSDEM
about this kind of thing [8] as well as a blog post with more detail
[9].

7: https://patches.dpdk.org/patch/43055/
8: https://archive.fosdem.org/2017/schedule/event/patchwork_jenkins/
9: https://that.guru/blog/patchwork-and-ci-in-a-tree/

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 there are also some review activities that are better done at
scale. One example I can think of is comparing the contents of source
tarballs and store outputs for new packages to those of existing
packages. If there is some overlap, it may suggest that there is some
bundled code/data that could be removed.

Let me know if you have any thoughts,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

             reply	other threads:[~2018-10-31 10:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 10:43 Christopher Baines [this message]
2018-10-31 13:34 ` Patchwork + automated checking and testing of patches Tobias Geerinckx-Rice
2018-10-31 13:53   ` Christopher Baines
2018-11-01 15:22 ` Ludovic Courtès
2018-11-01 18:55   ` Christopher Baines
2018-11-06 13:26     ` Ludovic Courtès
2018-11-06 15:13       ` Gábor Boskovits
2018-11-06 18:52         ` Ricardo Wurmus
2018-11-07 18:40       ` Christopher Baines
2018-11-07 22:00         ` Ludovic Courtès
2018-11-19 19:32 ` Christopher Baines
2018-11-22  9:07   ` Ludovic Courtès
2018-12-02 22:45 ` Chris Marusich
2018-12-03  0:51   ` Christopher Baines
2018-12-08 21:27     ` Chris Marusich
2019-02-01 12:53 ` Christopher Baines
2019-02-04 21:20   ` Ludovic Courtès
2019-02-08 12:04     ` Christopher Baines
2019-02-08 18:54       ` Björn Höfling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8h29z2j.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).