Patchwork v2 and beyond

[Stephen Finucane]

On Sun, 2017-06-25 at 14:23 +1000, Daniel Axtens wrote:
> Hi all,
> 
> So, Andrew, Russell and I had a chat about what we'd like to work
> towards for future versions of Patchwork:

Thanks for putting this together. My thoughts are below, followed by my own
take on this. Let me know what you think :)

> * Things before v2 comes out:
> ** 1 series per patch
> 
>  We think this is a solid idea.

Series incoming shortly.
 
> ** Release a tested version:
> 
>  We'd really like to see Patchwork v2.0 either be based on an unchanged
>  release candidate, or a release candidiate with only very obvious and
>  simple bug fixes. We really want to avoid the situation where people
>  upgrade and hit major bugs as that makes people want to avoid
>  migrating.

Yes and no. We're on RC4 already, which is kind of mad. If you look at the RCs
we've been releasing, most of them have been more about adding features to fill
holes or oversights than fixing bugs. I'm concerned that if we continue on this
trajectory, new features will keep coming in and we'll never get the release
out. To be honest, at this point I want to just merge the "single patch as
series feature" and, barring any serious issues from the below, release a final
version. We're not Debian, but we've done a lot of real world testing with
popular mailing lists and found very few issues. If we do encounter some later,
I'm more than happy to make PATCH releases as required. I'll hang on for the
fuzzing results, but after that I really want to cut this and move on to
getting it deployed and used in the real world.

> ** Fuzzing the parser
> 
>  The hope here is to find any as-yet-undiscovered failure modes in the
>  parser. I am hoping to do this in the next couple of days.

+1. This is the one other thing I'm willing to hold 2.0.0-final for, for better
or worse :)

> * For v2.0.1
> ** Django 1.11 support
> 
>  We need to keep up with Django, so this would be important.

I agree that we want Django 1.11, but it's a 2.1 target. PATCH releases are
only used to fix bugs, but Django 1.11 support is a feature. Given that no LTS
distro is packaging 1.11 yet and that 1.8 is still supported for the
foreseeable future, I think we're fine to wait a few months for 2.1.

> * For version 2.n:
> ** Version support
> 
>  We currently have the ability to record the version of patches/series -
>  we'd like to be able to integrate this in the UI. 

I assume you mean some way to switch between series? If so, that sounds good. I
think Andy Doan did some work on this?

> ** Check permissions
> 
>  A more sophisticated model for granting permissions for checks may be
>  helpful.

+1

> ** Events/ETags/Push API
> 
>  We've been talking about good ways to provide this. We should do it.

+1 - issue #2 is tracking this, and I'm planning to make use of django-channels 
to implement this. This will be optional, of course, to avoid deployment issues
for folks on distros without this package.

> ** Port pwclient to REST
> 
>  What it says on the box.

Getting support for REST is definitely a must. Ideally though, I'd like
pwclient to handle both APIs and gracefully fallback for unsupported operations
(series stuff) on XML-RPC. There are a lot of pre-0.9 Patchwork instances out
there and I'd like to keep supporting these for the next two to three years.

> * Version 3.0+
> 
> ** Drop Python 2 (and anything < Django 2)

Unless 3.0 isn't coming out until 2020 (when Python 2.7 reaches EOL), I'd hold
off on this. Python 2.7 support basically costs us nothing, and we want to
support both Django 1.8 and 1.11 for the full duration of their lifecycle.

> ** Extend the REST API so that we can separate the front and back end

This needs further discussion. I get that Single Page Applications and the
likes are all the rage these days, but implementing something like this is
likely to take a lot of time and deliver at best very minor benefits. Unless we
can deliver something tangible that hardcore Patchwork users will appreciate,
I'd rather expend that effort elsewhere.

> ** Drop XMLRPC

3.0 would probably be a good candidate for this, yes. By then we should have
most of the kinks with the REST API ironed out.

> Thoughts?

My few points aside, this looks pretty good. I do assume that there's an
implicit promise to contribute some of these full features yourselves? My own
priorities for Patchwork are slightly different, as seen below.

---

* 2.1

This will be a small finetuning release which will work on some of the stuff we
missed in 2.0.

** Bootstrap-ify the rest of the web UI

   Our web UI is very mismash and hasn't got any real love in 2.0. I'd like to
do some work on making it more consistent and approachable.

** REST support for pwclient

   See notes above. It's worth mentioning that I've already started work on
separating out pwclient into its own Git repo, but I plan to continue to use
the same mailing list for patch, bugs, etc. This leads us to...

** Multiple projects per mailing list

   We saw patches related to this recently. I'd like to support these.

** Remove Django 1.6, 1.7 support, add Django 1.11 support

   Removing these old versions is long overdue. With the new Debian out, we
need to do this.

** ETags

   Minimize hits to the API as much as possible

* 2.2

This will be a larger release which will add a couple of useful new features

** Proper series versioning

   We have multiple series versions. Now we need a way to show the link between
these in both the web UI and REST API.

** Check permissions

   As above. This might end up in 2.1 if it's small enough.

   See

** Labels

   See https://github.com/getpatchwork/patchwork/issues/22

* 2.3

** Web hooks/"push API"

   See above. This is out here because I really want to see if it's necessary
first (and not just a "nice to have"). It's going to result in significant
changes to the deployment method, so we need to make sure of this.

   See https://github.com/getpatchwork/patchwork/issues/2

* 2.4+

Who knows???

---

Hope this helps,
Stephen