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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
