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

Sat Nov 7 07:41:20 AEDT 2015

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]

> 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. 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]).

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

Stephen

[1] http://developers.slashdot.org/story/12/12/29/018234/
[2] https://github.com/getpatchwork/patchwork/commit/f7aeab077874d33fc99354661bfeedf508c292b3

> Regards,
> Mauro
> 
> PS.: I don't work at kernel.org infrastructure, but I have a strong
> feeling that they won't be changing from RHEL7 to a non-LTS distro
> nor I think they would be maintaining individual copies of upstream
> random libraries because of the newest patchwork version.
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork