distributed tests of a patch

Finucane, Stephen stephen.finucane at intel.com
Thu Aug 20 00:15:46 AEST 2015

> FWIW, I'm starting to look at this again as well. I'd like to have
> patchwork know about series first though, otherwise I don't think it
> makes much sense to test patches in isolation. A rough plan:

Series support is a necessity for CI integration with the API. However, the mail-based workflow that Thomas has suggested doesn't require this (we can parse the "series" using the raw 'message-id' and 'in-reply-to' headers). As a result, the "status-api" feature I proposed doesn't require series support.

>   - Land the UI redesign I have around
>   - Make patchwork learn about series (I probably have a "good enough"
>     state of this work that needs rebasing ie. I group patch into series
>     back from git send-email threads).

TBH I think you should split and prioritize the series feature over the REST API/UI redesign features. The latter features are nice-to-haves rather than absolutely necessary and could be done independently from the series feature. While initially it might seem like a waste of time to make UI/XML-RPC changes when these are going to be rewritten/deprecated, it will be far easier to review/merge than a series containing all three changes (or three series that depend on each other). I have started splitting out the series changes but it would be better if you did it, considering you know the code best right now :)

>   - Expose "New series since the last time I checked" API, probably
>     through the REST API that comes with the previous point

Why not XML-RPC? REST is definitely "the modern way" to do this stuff, but XML-RPC works perfectly at the moment and is already integrated into patchwork.

>   - From there, I probably want to hook it to jenkins, either writing a
>     new plugin or re-using one if the polling API is the same as another
>     tool already does
>   - Have some git integration where one can pull and apply a whole
>     series to a tree (as the first step for testing the patches):
>     $ git pw-am series 2341	# where 2341 is the series id of the
> 				# patchork instance configured in
> 				# .git/config
> --
> Damien


PS: Why yes, I *do* get the irony of asking you to split up patches (or rather, series) :)

More information about the Patchwork mailing list