distributed tests of a patch

[Damien Lespiau]

On Wed, Aug 19, 2015 at 03:15:46PM +0100, Finucane, Stephen wrote:
> > 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.

I haven't quite dove into the proposal, just wanted to say I'm also
interested by that with an outline of what I'm planning to do (which may
or may not happen, as always, but at least I do have some time allocated
to that now).

> >   - 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 :)

That does seem reasonable, except that the series UI part is based on
the UI rework. It should be too bad, the previous feedback was positive
and the number of comments to address low.

> 
> >   - 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.

Of one of the main thing is being able to re-use the API entry points
from the web page itself (say using jquery's ajax). That makes the UI
much nicer to use and reduces what the server needs to do (no full page
reloads).

It also forces us to think in terms of objects and methods and have a
clear separation between the backend and frontend(s). Right now the
XML-RPC API feels like a bunch of disjointed functions. We also mix the
views with API and have a number of "random" API entry points as POSTS
requests on view.

-- 
Damien