On Wed, 2017-09-06 at 23:59 +1000, Daniel Axtens wrote: > Stephen Finucane <step...@that.guru> writes: > > > On Wed, 2017-09-06 at 02:35 +1000, Daniel Axtens wrote: > > > > When I pushed the last change, I noticed that Travis was beginning > > > > to fail due to db permission errors. This is a trivial fixup. > > > > > > As this is: > > > - a trivial fix > > > - needed to get Travis to work > > > - tested in my postgres work > > > ... I have merged it to master at > > > 10a132f134cef46aabb01ca88a32d06bdc8cf320 > > > > > > Because we'll do at least one 2.0.n point release, I figure it's worth > > > having in stable, too. So I have merged it to stable/2.0 at > > > 8940289eeec123b9f8330bb54d8a3ee8b98c83af > > > > > > Happy to revert or modify if this is problematic. > > > > Nope, that makes sense. If Travis isn't testing stable/2.0 then I should > > probably fix that. Will investigate today. > > As you have probably discovered by now, it is testing that - indeed it > automatically tests all branches: > https://travis-ci.org/getpatchwork/patchwork/branches
Yup, no extra configuration necessary, which is great. > > I'll review the PostgreSQL patches you sent this evening and see which of > > backportable. After that, I think v2.0.1 is probably in order. > > Agreed. We're going to need to make some tough choices on the v2 > performance regression caused by the django bug too - do we want to > monkeypatch that or push it to sysadmins? I haven't looked into this fully yet, but my gut feeling (not always to be trusted) is that this is a sysadmin/packaging problem. ozlabs could carry the patch locally, but we should probably be looking for Debian/Django to backport the change. I do still need to look into it in depth, however. Stephen _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
