Patchwork 3: potential feature removals

Tue May 1 01:16:11 AEST 2018

Stephen Finucane <stephen at that.guru> writes:

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

So long as we can drop Python 2, I can live with that. There is *so*
*much* truly awful 2 vs 3 code, and there are known bugs with Py2
(e.g. handling of encoded UTF-8 names in the From field that was
reported on the list a while ago.)

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

Correct.

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

I think by the time we get 3.0 out the door this should be pretty stable
but we can make the call later.

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

We'll see, I guess. I'm not committed to this either way, but I am
committed to proper parallel series parsing.

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

It's just twice as much work for me in testing. I try to test with both,
and when doing performance work that gets really really tiresome.
Postgres also seems to perform *much* better, and I trust it more. If
no-one uses it in production, why go the effort.

FWIW, to drill down a bit, it's trivial to develop with postgres: just do
'docker-compose -f docker-compose-pg.yml <blah>'. I do this pretty much
exclusively.

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

Sure. That sort of comes under 'new features' - which I'm completely
open to! - I'm really just talking about stuff I want to drop in this
thread.

Regards,
Daniel

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