On Wed, 24 May 2017 18:14:54 +0200 Rhonda D'Vine <rhonda@deb.at> wrote: > * Neil Williams <codehelp@debian.org> [2017-05-24 16:42:47 CEST]: > > 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 > > That is no RC bug. Actually I fail to see why it is not considered > release critical that there is no upgrade path from stable to > stable+1. That's a very core principle of expectation. > > > > 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 can understand the pain involved, but additionally to the above, > has it occured to you at any point during that time to get in contact > with the backports team? Backports is not the place to fix bugs in > stable, or for the upgrade of stable. As LAVA upstream, we do not expect users to ever go from jessie to stable without going via backports, just because of the rate of change upstream. > Again, I very much understand now that this is an extremely > disappointing situation we got into here, but let me put the emphasis > here: backports is *NOT* the place to fix bugs that happen in stable. As far as LAVA is concerned, we do not do that. We upload new releases (which include bug fixes but a lot else) to unstable which migrate to testing and which then get backported to jessie so that production instances of LAVA can get the new upstream release on a jessie base. Once testing was frozen, we moved to external repositories hosted by Linaro for the subsequent production releases, using packages from backports for some dependencies. Sad to say but the current structures in Debian cannot actually keep up with user needs. > Please get your things fixed properly to not leave users of plain > stable in the blind. This is not acceptable, no matter how much I > can relate to the pain it involves. I think it is a misunderstanding to think that all users will go directly from the last jessie point release directly to stretch. Whilst base systems will do that and it makes things a lot easier to test in places like piuparts, it does not actually reflect reality. For this reason, I do not consider the jessie -> jessie-backports -> stretch upgrade path to be a problem. Indeed I see it as the only realistic option. > I'm deeply disappointed that at no point there was the try to get in > contact with us, and I'm sorry to tell you, you got yourself into that > mess yourself without consulting all the involved parties. This is > not our fault, but the way you handled it makes it look like it's > ours to solve. Please understand that the pressure and expectations > this puts on us is a very painful one, too. From my perspective, I believe I've been using backports properly. Equally, I fully understand why 1.8LTS has to be in backports (or at the very least available at the point where users migrate from jessie to stretch). > Also it shines a completely different light on the situation: This > is different than what Raphael explained. It is not so much anymore > about avoiding to have to adapt some tracker code because the 1.10 > version isn't code-compatible (which IMNSHO is a bad reasoning for > not following the rules), this is much much bigger than what came > through so far. And once again: Please speak to us. In time. With 1.8LTS in backports, everything was fine, I had no problems to raise - until the (IMHO artificial) limitation of a direct upgrade was superimposed. > That > way we can try to find a solution. Together. And not get into the > mess where we are right now where there not much possibilities to > move forward, because either way is a mess, for everyone. I was not aware of the problems with upgrading from jessie to stretch until 1.10 arrived in stretch. Stretch installs work, Jessie installs work, Jessie installs with backports work and Jessie installs with backports can upgrade to Stretch trivially. All that we were routinely testing upstream. Those are all of the upgrade and install paths which we support for users. The upgrade from jessie directly to stretch is atypical. Real production instances would not go directly from jessie to stretch because the level of changes in the test support is too large. > Personally, I'm really highly disappointed by the whole thing, by the > lack of communication, in time and also about the reasoning coming up > very late, and I'm uncertain where to move with this now. I'm > exhausted from the way the discussion went (and I am aware that I > played part in it, and am sorry or that), but there is one thing I > cannot accept: Playing with fake cards. That winds me up very much. > > Thank you a lot, Neil, for giving a very deep view into the issue at > hand. It's a deep view but there still seems to be disagreement on which package is at fault. So I'm just reporting the problems as we experienced them. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpEBACUUUoZS.pgp
Description: OpenPGP digital signature