Patchwork 3: potential feature removals

[Veronika Kabatova]

----- Original Message -----
> From: "Daniel Axtens" <dja at axtens.net>
> To: patchwork at lists.ozlabs.org
> Sent: Thursday, March 22, 2018 12:17:20 AM
> Subject: Patchwork 3: potential feature removals
> 
> Hi all,
> 

Hi,

> Patchwork is currently quite complex. This is adding to the bug surface
> and impacting reliablity - which as the recent issues have
> reinforced, is a fundamental feature for our users.
> 
> Patchwork is also maintained by a small, loosely-coordinated team of
> unpaid volunteers, and this stuff is increasing the maintenance burden,
> making working on patchwork more difficult and significantly more
> unpleasant.
> 
> I'm considering the following for the next major version of Patchwork -
> basically what will come after 2.n bug and stability fixes. Semantic
> versioning requires me to call it Patchwork 3, even though I expect
> user-facing changes to be very small compared to the 1->2 change. I'm
> looking at a timeline of the tail end of this year, but being patchwork,
> who knows when it'll eventually happen.
> 
> Please let me know if anything is particularly of concern or interest to
> you.
> 
>  1) Support Django 2.0+ only. This implies Py3 only.
> 
>  2) Drop patch status change notifications, and the associated opt-in/outs.
> 
>  3) Drop XMLRPC. pwclient will be rewritten to use the REST API.
> 
>  4) Drop the ability to disable tags for a project. Every project will
>     use the tags configured for the instance.
> 
>  5) Drop Patchwork specific headers, except X-Patchwork-Hint: ignore.
>     (i.e. X-Patchwork-State and X-Patchwork-Delegate.) I'm not sure if
>     they're used and I think they would be quite surprising to a lot of
>     project maintainers and users.
> 
>  6) (Possibly) drop support for piecing together unthreaded
>     series. (When someone sends patches not in reply to the first
>     patch/cover letter.) I think this will make correct series parsing
>     easier in the presence of parallelism; if not I'm happy to keep
>     it. (I think it might actually be nigh-on impossible to do both
>     correct parallel parsing and support unthreaded series, but I
>     haven't properly tried yet.)
> 
> I would also really, really like to drop MySQL, unless anyone uses it in
> production. If you are using it in production, please, please let me
> know. Please also let me know if you'd be willing to migrate to Postgres
> if I provide a migration script.
> 

I like these ideas. Upstream support for Py2 ends in 2020 so moving
towards Py3-only codebase makes sense. As long as the
    X-Patchwork-Hint: ignore
stays, I don't care much for the features mentioned (and some of them,
like the delegate header can be worked around, eg this one by the
autodelegation rules).

> I'm still happy to take patches for new features from the community -
> please don't interpret this as any sort of feature freeze! (Having said
> that, I'd be even happier to take bug fixes, performance fixes, and
> general cleanups!)

Happy to hear that, since we still miss a bunch of features we'd
eventually liked to get upstream :) (and of course bug fixes if we run
into any issues). That said, the reason why I'm writing this email is
because I'd like to help out with the cleanup as the times comes.
Please don't hesitate to reach out.

Veronika

> 
> Regards,
> Daniel
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork
>