On Fri, 2018-04-06 at 03:02 +1000, Daniel Axtens wrote:
> TL;DR: I want to spin a new version of patchwork for OzLabs so they can
> do the migration that speeds up patch listing. I've pushed it to
> https://github.com/daxtens/patchwork as I'm not sufficiently confident
> in my release-fu to push it to the main repo just yet. Let me know if
> it looks good.
Still need to go through the changes but I've left my thoughts below.
> From the release notes:
> Patchwork 2.1.0 - the Extra Special OzLabs Edition
> The key part of this release is a major performance fix -
> denormalising the project field into patch model so that counting a
> project's patches doesn't require a JOIN. This requires a migration
> and so isn't suitable for a stable backport. Event listing in the API
> has also been sped up by refactoring the queries.
> This release also includes the feature development that had accured in
> the mean time, as laid out below*, and numerous bug fixes.
> * not in this email, see the patches.
> Some other thoughts/notes:
> * I've pushed this to https://github.com/daxtens/patchwork as I'm not
> sufficiently confident in my release-fu to push it to the main repo
> just yet. This includes a tag, v2.1.0-rc1. Stephen, absent any
> rants from you I will push it to the real repo mid-next week
> * I know the patch counting isn't a full fix of everything that could
> or should be denormalised, but it's an ongoing problem and I don't
> want another 6 months of maintainer-guilt about the ongoing impact
> it's having.
That's fair. From the looks of things, it does get us 70% of the way to
what we want so that may be good enough. More on this in a bit though.
> * Normally releases are named after a fabric, but it's hard to find
> good fabrics beginning with E, at least according to the wikipedia
> list. I am very open to renaming/rewording stuff, hence the emails
> with the patches!
> * There's a decent chance I've missed a version number somewhere -
> please check your favourite locations!
We probably want to bump the API version to 1.1 too. I _may_ have
already done this though. If nothing else, we should note the bumped
API version in the release notes.
> * What else do we want in 2.1? I think at least the return code fix -
> it needs a v3 from me. (I would have done that first but I really
> wanted to get this out tonight/this morning for general awareness
> and comment.) I'm happy to take any more fixes or small things, but
> probably not big things. Feel free to post them and we can review
> them and get them ready to merge as soon as we tag 2.1.0 though!
I've got some API usability improvements incoming. Other than that it's
just the Events JSONification which I'd like to have a go-no go
decision on. I'll try to work on the migration for that this weekend.
> * Testing and general feedback would be appreciated. :)
> Thanks all for your contributions to Patchwork!
> Daniel Axtens (2):
> docs: Prepare for 2.1.0-rc1
> Patchwork v2.1.0-rc1
> docs/conf.py | 4 ++--
> docs/index.rst | 1 +
> docs/releases/extra-special-ozlabs-edition.rst | 33
> docs/releases/index.rst | 1 +
> patchwork/__init__.py | 2 +-
> 5 files changed, 38 insertions(+), 3 deletions(-)
> create mode 100644 docs/releases/extra-special-ozlabs-edition.rst
Patchwork mailing list