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

[Damien Lespiau]

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.

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.

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.

-- 
Damien