[Python-modules-team] Django 1.9

Raphael Hertzog hertzog at debian.org
Thu Dec 3 16:13:35 UTC 2015


Hi,

On Thu, 03 Dec 2015, Chris Lamb wrote:
> As as large "end-developer" of Django projects and Django components,
> the drawbacks of not having the latest version as possible in the stable
> release (and thus being uploaded to unstable) would personally far
> outweigh the benefits of sticking with a version with an "LTS" label.

This I can understand. It's also part of the reason why I like using
unstable. To always have the latest version of everything.

> Not having, say, 1.9 in stretch would be technically frustrating, not
> only in the literal sense of missing features that I would like to
> utilise, but also in that they might necessitate requiring sub-optimal
> solutions such as dh-virtualenv, etc. to circumvent cleanly or
> efficiently - using a hypothetical 1.9 from -backports would not
> sufficient due to the useful libraries typically not being reliably
> backwards-compatible.

I don't understand this comment about "useful libraries not being reliably
backwards-compatible". I have run tracker.debian.org on wheezy with Django
1.7 of wheezy-backports and it was fine... and if other libraries need to
be backported, then so be it.

> Furthermore, I would find it politically/socially awkward in that asking
> fellow developers to stick to what they could rightfully perceive as an
> "ancient" version of Django to satisfy some policy in another operating
> system an uphill battle and barrier to contribute. The meme of "Debian
> is old" is, in itself, also somewhat tedious and worth combatting in
> itself.

I'm sure we can find examples of the opposite. Not everybody wants to
upgrade their applications every 8 months so I'm quite sure we will find
many upstreams that support only Django LTS and who will release fixed
versions only when the next LTS comes out.

So packaging non-LTS release puts an increased burden on package
maintainers when their upstream expects Django LTS. Although to be fair,
if uptsream fixes properly the Django warning emitted with the LTS
version, then the code should continue to run with LTS+1 and LTS+2...

> What, exactly, are we worried about? My experience of investigating and
> handling of security issues in very old versions of Django are that they
> are usually trivially backportable anyway.

I have done 9 out of the 15 updates in squeeze and while this is often
true, there have been cases where issues affected parts of the code that
had diverged a lot and where the backport has been a headache.

So I would rather appreciate if we were actually shipping LTS versions in
stable... but given the upstream schedule is entirely inverted with the
Debian release schedule, and given the above considerations, I wonder if
we should not continue to package the latest upstream releases in
unstable but upgrade the (non-LTS version in) stable to the next LTS when
it arrives and stick to that version afterwards.

For this to be viable, we would just have to ensure that all Django
applications are free of Django warning before any Debian release.

What do you think?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



More information about the Python-modules-team mailing list