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