[PATCH] travis: switch to using root user

Stephen Finucane stephen at that.guru
Thu Sep 7 00:25:00 AEST 2017


On Wed, 2017-09-06 at 23:59 +1000, Daniel Axtens wrote:
> Stephen Finucane <stephen at 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


More information about the Patchwork mailing list