On Wed, 24 May 2017 21:06:35 +0200 Christian Seiler <christian@iwakd.de> wrote: > On 05/24/2017 04:28 PM, Neil Williams wrote: > > On Wed, 24 May 2017 16:23:13 +0200 > > Joerg Jaspert <joerg@debian.org> wrote: > > > >> On 14682 March 1977, Neil Williams wrote: > >> > >>> Policy is not a stick to bash developers or users. 1.8 needs to > >>> stay available in backports at all costs. > >> > >> Backports is not there to fixup maintainers mistake. > > > > It's not a mistake. It is simply a timing issue. There was no > > window to get the LTS into Jessie. > > But it was a mistake to upload 1.10 to unstable when it was > known that there isn't an upgrade path from the previous > stable version - and even worse that doing the upgrade anyway > would cause data loss. (If I understand this thread correctly, > at least.) The problem became known *after* the upload of 1.10 but not before 1.10 had replaced 1.8 in testing. > To take a step back a bit: let's say Debian (N-1) has version > X of a software, and Debian (N) has version Z. If you then > have versions X < Y < Z, then I have read two arguments as to > why one might want to keep version Y in (N-1)-backports: > > 1. Backporting Z to (N-1) is technically infeasible, but Y > offers substantial benefit for users of (N-1) over X that > is included there. > > 2. Upgrades from X to Z don't work, and need to go through > Y. > > I think argument (1) is debatable, and there are some merits > to it - but I'm going to ignore this for now, because: > > What I am utterly dismayed about though is that people here > consider (2) to actually be a valid argument. Forget backports > for a second here, Debian policy has always been that upgrades > from (N-1) to (N) have to work and be self-contained - > anything else is RC. So in this case, the current Django > package in Stretch should NOT be released as-is. (Which is the > meaning of RC.) And if you ask the release team, I'm pretty > confident they will agree with that. That was not how I understood it at the time. > [1] Put yourself in a > user's perspective: one of the main selling points of Debian > (for good reason) is that one can actually dist-upgrade one's > system and the vast majority of things will just work. Now this is where things get awkward. For most packages, yes, this can work. For complex packages, this can be problematic and this rule then gets in the way of helping users upgrade. > And > while there are always preparations steps necessary for an > upgrade - and sometimes one's local configuration needs to be > migrated manually - what has nearly always been the case is > that maintainers have put in a lot of work to ensure that > the upgrade path is sane. And sure, if I'm a power user of > Django and use it for my own projects, then I probably won't > mind going through some extra hoops in order to upgrade it. Which is how we've been handling LAVA upgrades, partially because we're towards the end of a 4 year migration process to a completely new design of the software to make things easier to deploy, test and triage. Right now, LAVA users need to update to each new production release. There isn't really the option of staying on whatever is in Jessie, too many devices just cannot be supported by the code as it was at that point in time. New device support is added all the time and the code needs to be upgraded to allow for the idiosyncrasies of these early prototypes so that when the boards are released, everyone else gets a reliable kernel boot and firmware etc. > But what I really don't want to have to do as a user is if > I install a specific package that uses Django internally, > that I then have to deal with these kinds of issues. Please > extrapolate for a moment: today this is just Django, then > tomorrow the $Some_RDBMS people come along and want to do the > same thing and before you know it as a user you have to > manually upgrade 20 different large sets of packages to a > backports version (or a version in a Bikeshed/PPA) before > actually going through with the dist-upgrade. > > But even if you say "ok, for this one time we need an > exception from the normal rules" - as far as I can tell, this > thread is the first time this has been brought up with the > backports team (and only because an upload was rejected), and > the release team hasn't been involved either as of yet. And > apparently nobody involved in Django even though about > updating the official Jessie release notes about this, and it > was somebody else who filed the corresponding bug. [2] Specifically, backports was being used correctly with the initial upload of 1.8LTS and corresponding backport. LAVA needed to update from 1.7 to 1.8 as it is the LTS and numerous issues had to be solved. LAVA did this with a new upstream release which went through unstable and testing and into backports. All was good, backports team would not have had any problems at this time, there was no need to alert anyone, there were no issues and no rules had been bent. LAVA continued to build on 1.8LTS support in backports but at a later date, 1.10 was uploaded to unstable, migrated to testing and the 1.8LTS backport was left dangling but critically important as it is the LTS. I've spent a lot of time trying to debug the failure going from 1.7 to 1.10 but it seems like it is just an untested code path in that LAVA must apply the database migrations in the maintainer scripts to support the running scheduler and the running test jobs. If we get 1.8 back in Stretch we fix the current issue and as mentioned elsewhere on this thread, the LAVA software team are now tasked with doing the validation that packages like LAVA can upgrade smoothly from LTS to LTS+1 if Debian keeps to only having the django LTS releases in unstable, testing, stable and backports. We are where we are and I apologise for not mentioning this to others earlier but I've been trying to work out what the problem is whilst still driving forward the upstream work to complete the long term migration to the new system. There are only so many hours in the day and so many days in months. > [2] If I understood this thread correctly, not upgrading via > the intermediate version will lead to data loss. > > So let me get this right: this issue was not communicated > to the proper channels at all, and had Alexander or Rhonda > not rejected the package from backports in order to > trigger this discussion, the Stretch release notes would > likely not have been updated (nobody from the Django > maintainers appears to have had any interest in triggering > this). And if after the release of Stretch a user had > decided to do a direct upgrade from Jessie to Stretch > (thinking that because there's nothing in the release > notes, this sould be safe), they could have experienced > serious data loss? If 1.8 remains in backports then the data loss can be mitigated *if* the user concerned reads the LAVA documentation. News.Debian.gz is frankly useless for this situation as nearly all of these instances are upgraded remotely and automatically. If 1.8 goes into Stretch, the problem goes away entirely - at least until we get to Buster and have to think about possibly migrating LTS -> LTS+2. Again, we will put in the automation to address that, once LTS+2 release candidates are available in experimental. Alternatively, Debian lets 1.8 be updated in backports with 1.10 in Stretch and then replaces 1.10 with 1.11LTS in unstable and make a clean start with a backport of 1.11LTS into stretch-backports and later developer release (2.0 and 2.1) going exclusively into experimental, with the automation support to validate upgrades. > Please, please tell me I misunderstood something here... Within LAVA we have comprehensive documentation and we include in that the process of installing updates via backports. Due to the nature of the current migration, it is extremely unlikely that anyone running LAVA from jessie would contemplate upgrading that version to Stretch as the migration plan would involve disabling most of their devices. I think there are areas of Debian where software as a service is poorly served and that it is unrealistic to expect that a service would be left stale for the lifetime of a stable release with only security updates during a time of massive transition in the project providing that service. The reality is that many of these services are not in Debian and the main reason for that would be that it is difficult to be in Debian when rules like this are applied harshly. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpZU1n4GGd6K.pgp
Description: OpenPGP digital signature