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

[Mauro Carvalho Chehab]

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

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

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.