Re: Maintaining intermediary versions in *-backports
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.)
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. [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. 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.
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]
Regards,
Christian
[1] I remember a couple of instances where packages I was
using have been removed from a stable release just before
or during the freeze because they didn't provide a valid
and self-contained upgrade path. So this is really not
unprecedented.
[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?
Please, please tell me I misunderstood something here...
Reply to: