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/ _______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
