On Wed, 24 May 2017 15:42:47 +0100 Neil Williams <codehelp@debian.org> wrote: > On Wed, 24 May 2017 17:21:21 +0300 > Adrian Bunk <bunk@debian.org> wrote: > > > On Wed, May 24, 2017 at 03:06:07PM +0100, Neil Williams wrote: > > >... > > > Upgrading 1.7 to 1.10 without going via 1.8 will break all > > > packages with django as a dependency. That is not a "normal > > > risk", that is RC - causes data loss. > > > > Why is no RC bug filed against the version in stretch? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847277 > > > >... > > > It is quite something else to say that NOBODY can upgrade existing > > > installations from jessie because the critical package in > > > jessie-backports has been removed. > > >... > > > > This is not an upgrade path documented in the current draft of the > > release notes, and a package in backports being required for an > > upgrade is simply wrong. > > I disagree. We have taken great pains to ensure that our own > documentation covers that jessie-backports is mandatory. > > I'm just trying to keep the plates spinning for our users. The Debian > release notes are general and high-level. There will always be issues > which cannot be covered in those notes which affect particular > sections of users. We've tried to address that upstream for the > benefit of our users. > > To be fair, our users are already all using jessie-backports as the > support for their production systems and we test that particular setup > intensively and constantly. We provide the assurance that > jessie-backports is ready for production for *our specific use case* > because we have the data to prove it. > > > Based on what you say the only real options are: > > - ship both 1.8 and 1.10 in stretch > > As 1.10 is a developer release still, I'm not sure what that gives us. > > > - go back to 1.8 for stretch > > That is a short term fix but it is a fix for the immediate issue and > for the dependency packages. 1.8LTS will drop out of security support > upstream before the end of the stretch cycle. > > https://www.djangoproject.com/download/ > > Separately to this thread, I have been talking to the django > maintainers in Debian, specifically Raphael, about providing the > requested automation support to provide assurances on upgrading from > 1.8 to the next LTS, 1.11 and on to the LTS+2, django 2.2LTS. > > That plan would also push developer releases of django into Debian > experimental only. This means some changes for maintainers and > upstream developers of packages depending on django to test their > code with packages from experimental to head off any problems with > the upgrade to the next LTS. > > However, this is workable. Disclaimer: I'm saying this from my own perspective - my particular package is known to work with 1.8LTS because that is how the majority of production instances of LAVA are using django. The package is also known to work with 1.10 from stretch because - as a responsible maintainer - I run my own LAVA instance using 1.10 (I'll be testing with 1.11 which is in experimental too). I cannot say the same about other django reverse dependencies - I've only tested what I run. I don't know if other packages using django would break with 1.8 at the versions currently in stretch. I hope it is unlikely as 1.8 is the LTS but I've not tested these myself. > > > As a side effect, either of these would permit 1.8 in > > jessie-backports under the existing rules. > > It would, although I fear it is just storing up problems for the > stretch -> buster cycle when we will need to try to go from 1.8LTS to > 2.2LTS without having 1.11LTS available in the archive. > > Even having 1.11LTS in Buster as well as 2.2LTS isn't a > straightforward solution because dependencies may need to have a new > upstream release which works with 1.11LTS and then a separate release > which works with 2.2LTS. Code that works without warnings from 1.8LTS > is expected to work with 1.11LTS but not necessarily with 2.2LTS. > > I'm not sure how best to handle that one. It adds fuel to the flames > that Debian ships out of date software by default. > > -- > > > Neil Williams > ============= > http://www.linux.codehelp.co.uk/ > -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpLGIACUpQzD.pgp
Description: OpenPGP digital signature