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

[Mauro Carvalho Chehab]

Em Fri, 06 Nov 2015 20:41:20 +0000
"Finucane, Stephen" <stephen.finucane at intel.com> escreveu:

> On 06 Nov 15:57, Mauro Carvalho Chehab wrote:
> > Em Fri, 6 Nov 2015 15:52:02 +0000
> > Damien Lespiau <damien.lespiau at intel.com> escreveu:
> > 
> > > On Fri, Nov 06, 2015 at 12:25:18PM -0200, Mauro Carvalho Chehab wrote:
> > > > > Django 1.8 is LTS so I imagine there should be support coming for this in
> > > > > EPEL, SLES etc. I'm little to no experience with these distros though, and 
> > > > > I have no idea how these folks plan/publish their roadmaps. Could you advise?
> > > > 
> > > > It doesn't matter whatever version Django maintainers decide to be their
> > > > LTS version if they don't sync it with the LTS distro releases.
> > > 
> > > > The point is: it is a very high risk to run patchwork on any serious
> > > > projects like the Linux Kernel on some server that doesn't run a LTS
> > > > distribution.
> > > > 
> > > > It is also a serious risk to manually maintain its own manually
> > > > maintained packages on an LTS distro, as you may risk forgetting to do
> > > > some important security upgrade because the fix is not packaged by
> > > > inside the distribution.
> > > 
> > > Just for the record, my opinion on this: there are definitely good
> > > reasons to want to use distribution packages, but that's the usual
> > > distro packages vs upstream versions/branches discussion. That's
> > > especially true for even newer trendy things like Node.
> > > 
> > > I'd ask for a slice of empathy here. Demanding that a project
> > > dependencies are based on the union of supported LTS releases across
> > > distributions will hurt the project. Having constraints like "Patchwork
> > > has to work from django 1.4 until 2018 because of Debian 7" makes
> > > development a miserable experience.
> > 
> > I'm not a python developer, but for me it sounds that the big issue here
> > is that Django (and Python) seem to have a very bad tradition of breaking
> > applications because they're always breaking their APIs.
> > 
> > At least where I sit (Kernel development), we try to do our best to
> > make sure that the APIs wouldn't break support for applications developed
> > using an older version.
> 
> I thought it was userspace that should never be broken? I'm familiar with
> Linus'...light-hearted discussions on the matter :) [1]

He meant to say that Kernel should never break userspace, meaning that
the APIs should not break support for binaries compiled with an older
Kernel.

> 
> > I would say that, if Django has such huge problems of not allowing
> > apps to be backward compatible, maybe patchwork should try to use
> > something with a better design.
> 
> We can't drop Django, if that's what you're suggesting. 

No, I'm not suggesting that. Just saying that it sucks that newer
versions break apps written to work with the previous ones.

> I have some quibbles
> with how it's designed (monolithically) but to change would in effect require
> a rewrite. Evolution, not revolution, is the name of the game here.
> 
> > > That's an even bigger problem when adding more dependencies into the
> > > mix.
> > > 
> > > I don't need to on, people have discussed at length the impedance
> > > mismatch between distribution packages and upstream development. There
> > > are a number of solutions people use to decouple their web applications
> > > from the underlying system, I'd argue that's even one of the selling
> > > point of interesting things like Docker: Build your app with its
> > > dependencies, deploy!
> > > 
> > > So, I'll just ask if people could at least ponder the question on both
> > > sides before being very assertive about the "right" way patchwork should
> > > handle its dependencies and deployment. It's definitely not a black or
> > > white answer, I have seen package updates in distributions break
> > > applications as well for instance.
> > 
> > That should never happen with LTS distributions, as this is the selling
> > point of all LTS distros: APIs are stable, and applications should never
> > break when packages got updated.
> > 
> > > Security doesn't have to mean trusting the distribution (which in turns
> > > more often than not trusts an upstream), there is something to say about
> > > trusting an upstream directly.
> > 
> > You can't trust that upstream won't change APIs nor that upstream won't
> > be introducing new security bugs. After all, the goal of upstream
> > development is to introduce new features, and sometimes, things
> > accidentally break.
> > 
> > On the other hand, the goal of a LTS distribution is to provide a
> > stable and secure environment.
> > 
> > So, if one needs security and stability, the obvious choice is to use a
> > LTS distro. That's why kernel.org uses RHEL, and that's why and all other
> > servers at the Internet that aim to be reliable also use a LTS distro.
> > 
> > If you take other web apps like cgit, they're designed to work without
> > requiring the latest brand new libraries, as they rely on the APIs that
> > are known to be found at LTS distros. When new improvements are obtained
> > by using some specific newer version of some package, they have some
> > autoconfig logic that would detect the versions of the libraries and
> > select the corresponding options that would work best for the system
> > where it is being used.
> > 
> > Perhaps one solution would be to create separate branches for stable
> > versions of patchwork that could run with LTS distributions (and so
> > the version that kernel.org and other similar sites would be running)
> > and use the unstable "master" branch for those who are using patchwork
> > for some internal development and doesn't need the security provided by
> > a LTS distribution.
> 
> We've been doing much of this via feature flags. Unfortunately this only works
> so long as we don't rely on new features (i.e. migrations). When this happens
> we need to either (a) provide alternatives (manual SQL migrations) or (b) just
> embrace the new feature, thus dropping support for older Django versions (the
> management jobs? [2]).

I've no idea on how to do that with python, but you might have some script
that would either use manage.py (for newer versions of Django that supports it)
or keep using patchwork/bin/patchwork-cron.py on old versions.

But I see your point: maintaining both sucks.

> 
> All this means is we've to restrict ourselves to option (a) and, where this is
> not possible, avoid using the new, shiny feature.

True.

I see, however, one alternative to the dilemma of being stuck with an old
version of some library. As you said, you'll be soon releasing patchwork v2.0.
Assuming that the patches that dropped django 1.6 got removed, you will then
have a v2.0 branch running with Django 1.6. and keep maintaining branch v2.0
as an LTS version of patchwork, while using the master branch (or a v2.1
branch?) to do work that would use the new stuff at Django 1.8.

Depending on the time, the best would be to backport the new stuff that
won't depend on Django 1.8 to v2.0 and produce regular versions.

On some years, when the major projects migrate to the newer LTS versions,
they'll get the v2.1 of patchwork (or whatever newer version on that time).

Regards,
Mauro