distributed tests of a patch
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
PS: Why yes, I *do* get the irony of asking you to split up patches (or rather, series) :)
More information about the Patchwork