Patchwork 3: potential feature removals

[Stephen Finucane]

On Thu, 2018-03-22 at 10:17 +1100, Daniel Axtens wrote:
> Hi all,
> 
> 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.

Django 1.11 is the most recent LTS and is supported until 2020, as is
Python 2.7. I'd like to drop Django < 1.11 (which are all EOL now
anyway) and add support for Django 2.0. However, I would like to retain
1.11 support until 2.0+ is available in Debian testing. This suggests
delaying a 3.0 release until 2020 at least.

>  2) Drop patch status change notifications, and the associated opt-in/outs.

You're referring to the email notifications, rather than the '/events'
API, right? I definitely don't want the latter removed but I'm happy to
see the former go (people can write tooling using the REST API now).

>  3) Drop XMLRPC. pwclient will be rewritten to use the REST API.

Sure, this is definitely a 3.0 target. This has essentially no
maintenance cost at the moment and I'd like to allow more time for the
REST API to bed in.

>  4) Drop the ability to disable tags for a project. Every project will
>     use the tags configured for the instance.

Yup, there's no reason for this to be opt-out.

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

Fine by me.

>  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 _think_ there's some work we can do here wrt unique constraints that
might help us.

> 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'm not sure why we'd want to do this one. The only time I see MySQL
causing us pain is with differences for data migrations, which are few
enough to deal with it. FWIW, I only use MySQL for development (though
I'd be open to change if there was specific reasons to do so).

All of my objectives from the previous discussion on this still apply
too:

  https://lists.ozlabs.org/pipermail/patchwork/2017-June/004427.html

Finally, I'd like to make the REST API compulsory. Doing so allows us
to simplify some areas of the code and also allows us to use some of
the packages (like 'django-filters') elsewhere in the code.

Stephen

> 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!)
> 
> Regards,
> Daniel
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork