[PATCH v2 0/4] Remove support for Django 1.6

Finucane, Stephen stephen.finucane at intel.com
Tue Nov 10 04:13:18 AEDT 2015

> Hi Don,
> Em Mon, 09 Nov 2015 11:22:50 -0500
> Don Zickus <dzickus at redhat.com> escreveu:
> > On Fri, Nov 06, 2015 at 07:02:31PM +0100, Johannes Berg wrote:
> > > +Konstantin, the kernel.org sysadmin. The context is that patchwork has
> > > just removed (see subject) support for Django 1.6, but I've been told
> > > that RHEL/EPEL7 which you run has only that version, so updating to the
> > > latest patchwork would now be impossible (again)
> >
> > Hi,
> >
> > Just to throw another datapoint at folks.  RHEL-7 has this notion of
> > software collections.  It allows customers to update a collection tools
> to a
> > newer version (RH supported) in the /opt area.  Then using a script
> (which
> > sets env variables), a program can easily use python3 and postgres9.2 on
> > RHEL-7.
> >
> > You can read about it here:
> >
> > https://access.redhat.com/support/policy/updates/rhscl
> >
> > and talk with your RH account manager about more of the details.
> >
> > You would still need to pip install Django, but at least you could get a
> > newer supported python and postgres on RHEL-7.  Not sure how much it
> helps.
> > Again it was just another datapoint.
> The big issue is with Django, and not with python/postgres.
> As far as I understood, the impact at the database is only a side
> effect. It seems that each new version of Django uses a different logic
> to build the SQL tables. So, the SQL tables generated by Django 1.6
> are different than the ones generated by Django 1.8. So, the scripts
> that allow upgrades between patchwork versions are Django-version
> specific.

Not quite. If understand it correctly, the existing tables should be identical.
There will be one change, but this is to add a tracking table that tracks
which migrations have been applied.

Django 1.6 doesn't (yet) provide any additional technical challenges for us:
the challenges are purely overhead. Developers need to keep adding manual
SQL migrations to 'lib/sql/migration' and modifying the
'lib/sql/grant-all.[DB_TYPE].sql' files for each database change instead of
letting Django take care of this for us. Similarly, sysadmins need to validate
these migration scripts (we don't do it) before applying them. We can work
around these issues for now, but it's something we'd like to get rid of as
soon as it's viable.

> So, I guess that using RH Software Collections won't actually solve
> the issue.
> Additionally, not all projects that use patchwork uses RHEL7 for its LTS
> distribution. LinuxTV, for example, uses Debian.

Yes, this is a significant issue :) I actually considered submitting a
patchwork package to EPEL, but I'm (a) unsure as to the process here (though
I could find out) and (b) not sure how many people that would actually help.


More information about the Patchwork mailing list