On Wed, 24 May 2017 22:21:02 +0200 Raphael Hertzog <hertzog@debian.org> wrote: > Hi, > > On Wed, 24 May 2017, Rhonda D'Vine wrote: > > No, it's not stricter than what is written down. I'm sorry, this > > has gotten pointed out to you. You can disagree with reading it > > that way, and you (again) left out part of the explenation of the > > exception (which reads to take it directly from unstable instead of > > waiting for testing moving over). As long as you are unwilling to > > acknowledge that I fear we won't be able to have any useful > > discussion on that. > > Well, it's human nature to have two different interpretations of the > same text. With the way it is written, it really feels like that you > leave some leeway to maintainers as long as it upgrades sanely to next > stable. > > You have now both clarified that you did not mean that at all. Now > either you improve the text to remove the doubt, or you acknowledge > that letting some freedom to the maintainer is a good idea (we trust > us by default after all). > > I think I explained more than enough why I believe that some freedom > is needed and why it's acceptable. > > > See, and here actually is a very good argument to *NOT* use it that > > way. The lack of existing bikesheds/PPAs so far shouldn't be an > > argument to change the rules. When they finally will happen it > > would mean we should change them back so that people know what they > > can expect from backports. Right now, with your approach of > > ignoring the rules, people don't know what to expect, which I doubt > > is the better approach to anything. "backports might contain > > whatever someone deems useful, but no clue where it comes from and > > how it's maintained" is not a useful suggestion in my opinion. > > People's expectations are far below what the policy says because as > you pointed out yourself, many backports are not kept up-to-date with > what is in testing. > > My own expectations of stable-backports are: > - newer than in $stable and not newer than in $stable+1 > - created by a DD > - maintained by a DD on a best-effort basis > - hopefully with better security support than none at all > > That's all. I think we should acknowledge that this is what we are > providing. We are not able to always have the current version in > testing backported to stable. > > > The website has right on the front page a very clear statement on > > that expectations: > > > > ,-----------------> https://backports.debian.org/ <----------------- > > | Backports are packages taken from the next Debian release (called > > | "testing"), adjusted and recompiled for usage on Debian stable. > > [...] | (In a few cases, usually for security updates, backports > > are also | created from the Debian unstable distribution.)" > > `-----------------> https://backports.debian.org/ > > <----------------- > > That's correct. That's what they are... at one point in time. And > afterwards this is no longer true when testing evolves and when > backports are not updated. > > > I consider the case closed unless something new is brought up. We > > are turning in circles. > > I think we made some progress in the other thread already. > > Can you answer > https://lists.debian.org/debian-backports/2017/05/msg00112.html ? > > > Having a proper discussion means to not start to ignore the current > > system and then start an argument how unfair you feel treated. > > It's not about my feeling. It's about what brings the most value to > our users. The current policy doesn't let me use $stable-backports in > the most beneficial way for our users. Yes, my interpretation of the > policy is not in line with your interpretation. You want your way and > I want my way. > > Can we step back and think about what are the advantages/disadvantages > of both cases? > > Scenario 1: Keeping 1.8.x in jessie-backports > > Advantages: > - users can get this widely used LTS version from an official Debian > repository > - DSA can continue to use it to keep tracker.debian.org safe > > Disadvantages: > - nobody else can upload 1.10.7-1~bpo+1 as long as we want to stick to > 1.8.x in jessie-backports > => uploading to backports should be done with the maintainer's > assent anyway and I'm one of the maintainers, I would just explain the > rationale why it's important to stick to 1.8.x in jessie-backport > > Refuted disadvantages: > - maintaining another version than the one in testing makes it harder > to take over backport maintenance after me > => wrong because we can bump to 1.10.7-1~bpo+1 if we can no longer > maintain 1.8.x > > > Scenario 2: upgrade to 1.10.x in jessie-backports > > Advantages: > - we stick closely to your policy > - we have a newer version in jessie-backrpots (albeit a non-LTS one) > > Disadvantages: > - we inflict some backwards incompatible changes on the users who > opted to use 1.8.x from jessie-backports (unless they fixed > all the warnings they had with the former Django version) > - users of the LTS version cannot get it from an official Debian > mirror > - I have to figure out how to get updates installed with DSA > Scenario 3: replace 1.10 in Stretch with 1.8 Advantages: - the backport regains a link with Stretch - policy is maintained - the upgrade problems are solved (or at worst deferred) - no backwards incompatible changes for users Disadvantages: - epoch - (I've likely missed some others as it's more a question for Raphael.) Personally, I'm fine with 1 or 3 but 2 is not going to help users upgrade. > Now can you tell me what advantages/disadvantages I did miss that > would explain why following the policy is better than sticking to > 1.8.x? (This is not rhetorical, please try to formulate them so that > I can have a better understanding of your reasoning) > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ > -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpBt3rCkxqVv.pgp
Description: OpenPGP digital signature