Patchwork + the Guix Data Service for assisting with patch review

[Christopher Baines]

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 address@hidden

- 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

signature.asc
Description: PGP signature