Re: Maintaining intermediary versions in *-backports
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
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/
Reply to: