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. _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
