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

[Mauro Carvalho Chehab]

Em Fri, 06 Nov 2015 17:37:47 +0000
"Finucane, Stephen" <stephen.finucane 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.
> 
> 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.

Yes, I know. I'm not asking to re-add Django 1.4 support, but just saying
that my legs got broken when django 1.4 support got removed.

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

We won't. We don't want to increase the risk of attacks at linuxtv.org.
This is something that we've discussed already internally with the other
machine sysadmins. There, we'll be using only python/django/etc that are
provided by a LTS distribution (currently, Debian 7, but we'll likely
migrate to Debian 8 in some future).

I guess kernel.org also won't be installing Django from its sources,
but that's just my wild guess. I'm c/c Konstantin, as he's the one that
answers for kernel.org infrastructure.

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

If you need, you can reach me on IRC. My nick is "mchehab".

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