Patch tagging/classification

Damien Lespiau damien.lespiau at
Tue Feb 9 04:46:54 AEDT 2016

On Mon, Feb 08, 2016 at 05:19:37PM +0200, Ruslan Kuprieiev wrote:
> It looks fantastic, and it is exactly what I've been looking for for a long
> time now.
> Why aren't these features merged into base patchwork yet?

I wanted to make some fairly big design decisions that didn't resonate
well with where other people wanted patchwork to go: bootstrap, REST API
(instead of XML-RPC), series, test results API and result emails sent
from patchwork, git pw (instead of pwclient), use of the REST API from
the web pages, having dependencies not linked to what distributions
offer, ... So I went off experimenting.

I suspect it'll be hard and time consuming to reconcile the two

> How hard can it be to use your patchwork version for another project?
> I'm participating in CRIU[1] project and we would love to try your patchwork
> mod.

A note of caution, the two active patchwork branches have different DB
schemas, so choosing one branch means it'll be hard to migrate to the
other one.

I'm not sure if you already have a deployed patchwork instance. If so
and if you're using Jeremy Kerr's patchwork, both Patchwork branches are
a fast forward and support DB migrations.

Installing patchwork is quite involved though:
  - mail integration (how patchwork receives emails, there are many ways
    to do that)
  - Have a DB around
  - Web frontend to Django app
  - git hook on the repos to mark the patches Accepted
  - There's also a cron job (that I'd like to replace with a celery

As mentioned before, Freedesktop's patchwork has a somewhat strong
opinion on distribution dependencies. It favours deploying patchwork in
an isolated, sateless, WM/container (or at least in a virtualenv) with a
tight control on the versions of those dependencies (as opposed to
relying on the distribution packages). People have voiced concerns about
this, but I find it rather freeing.



More information about the Patchwork mailing list