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

[Finucane, Stephen]

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

We can't support Django 1.4: it's too long in the tooth and has been
unsupported for too long to even consider. We only just removed Django
1.6 support so I can consider rolling that back, but unless someone
else wants to contribute patches then it's not going to be viable to
support anything older.

> That's an even bigger problem when adding more dependencies into the
> mix.

You've identified another issue here: non-Django dependencies. At the moment,
we only rely on a very small set of requirements[1], most of which should be
available via system packages. If we can't use pip then we're going to be
very careful not to introduce dependencies that aren't provided by RHEL,
Ubuntu LTS, Debian etc. This is going to severely hamper developer velocity
so I'd like to know for sure that this is necessary before undertaking
anything.

> 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

So I think we need to answer the following question:

* Are deployers going to install from source/pip?

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.

Mauro: Johannes: Can you provide input here, or direct me to the correct
channels to get this information (mail or IRC).

Cheers,
Stephen

PS: There are a million of these on the net, but the Mozilla blog[2] details
installing from pip and the rationale for doing so. Just saying :)

[1] https://github.com/getpatchwork/patchwork/blob/946c5b72b2e3f9db851379c1cf68f1f9d7eebe7f/docs/requirements-prod.txt
[2] https://blog.mozilla.org/webdev/2013/01/11/switching-to-pip-for-python-deployments/