[PATCH v2 0/4] Remove support for Django 1.6
Mauro Carvalho Chehab
mchehab at osg.samsung.com
Tue Nov 10 03:54:22 AEDT 2015
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)
> 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
> You can read about it here:
> 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
So, I guess that using RH Software Collections won't actually solve
Additionally, not all projects that use patchwork uses RHEL7 for its LTS
distribution. LinuxTV, for example, uses Debian.
> > > We can't support Django 1.4: it's too long in the tooth and has been
> > > unsupported for too long to even consider.
> > It's also ancient and awful compared to newer versions :)
> > > So I think we need to answer the following question:
> > >
> > > * Are deployers going to install from source/pip?
> > I don't really know. Perhaps Konstantin can chime in.
> > > If not, then we're going to have (a) roll back the Django 1.6 removal
> > > patches, (b) put together a roadmap for future Django version support and
> > > (c) avoid using non-stdlib libraries (outside of Django) going forward. As
> > > Damien pointed out, these actions come with some rather severe costs for
> > > us so I'd like to be absolutely certain of this before I take any actions.
> > >
> > There's the obvious alternative of not caring about LTS installations
> > like kernel.org and simply continue developing the software as is
> > against upstream. *Eventually*, it's going to get to the users, perhaps
> > not as fast as the users (like me) would like.
> > And I'm not suggesting at all that you should consider "LTS distro"
> > support of huge importance.
> > I think in a way part of the problem is that your user audience is also
> > developers (in a different space), so we users might be interested in
> > working on tools improvements ourselves (like the regex auto-delegation
> > feature that Mauro/Laurent have), but there's less incentive to do that
> > if we can't actually benefit from it in a fairly short time frame (and
> > we're more likely to script our way around it instead.)
> > johannes
> > _______________________________________________
> > Patchwork mailing list
> > Patchwork at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/patchwork
More information about the Patchwork