[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