Patchwork 2.0 ready for takeoff?

[Stephen Finucane]

You may have noticed a small bump in activity in the last day or two as
I've merged a few patches and done some (significant) rework of the
docs. This is prep for the 2.0 release, which I hope to make next week.
As things stand I'm very happy with the current state of the REST API,
series support is working as expected, and the check API looks fit for
purpose. Daniel has been testing this locally and the couple of folks
that have been using the 'master' code [1] have reported the odd issue
but nothing calamitous. I think we're all set.

Now, there are a couple of things that I'd like to work on before the
release [2] but nothing that should block the release. Assuming I get
those out of the door, is there any reason that we can't (a) enable the
snazzy new REST API by default, (b) tag a 2.0 release some time next
week and (c) release and celebrate?

Cheers,
Stephen

[1] I've seen at the least the following:

- patches.linaro.org
- patches.opendataplane.org (same as above)
- patchwork.linux-mips.org

There are probably more. I should really index these.

[2] I really want to re-do the deployment guide for Xenial. 2.0 is a
pretty significant change and not only is Trusty old news now but I
imagine additional steps will be required to deploy it (DRF, at a
minimum).

In addition, I've found myself unable to filter patches uses the
slugified states (i.e. '/patches/?state=new') yesterday using master. I
don't know if this is a regression or not, but I really want this for
'git-pw'.

Finally, we still don't have anything done for rate limiting in the
REST API. Personally, I wouldn't consider this a blocker as it's easy
to enable (it's simply not done by default). However, we might want to
at least set a somewhat safe default.