Re: Maintaining intermediary versions in *-backports
On 05/25/2017 12:53 PM, Neil Williams wrote:
> On Wed, 24 May 2017 21:06:35 +0200
> Christian Seiler <christian@iwakd.de> wrote:
>> 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.
But this is absolutely nothing new. This rule is nearly as old as
Debian itself. I really don't understand how there could be any
misunderstanding about this from package maintainers?
The only mistake I made above is that I assumed from reading your
earlier messages in this thread that the problem is in Django,
which I've now learned is apparently not necessarily the case,
because other Django software doesn't seem affected by this.
>> 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.
But instead of communicating this with e.g. the release team, you
unilaterally decided to just break this rule, and didn't even
initiate the process of updating Debian's release notes?
>> 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.
So why not involve the release team at this point? Together with the
Django maintainers? To find a solution to this early? Maybe they
could have helped here?
Taking a step back: one of the key problems of keeping an intermediate
version in backports that was brought up here was that then the
backport will rely entirely on the person currently maintaining it,
and if that person were to disappear for whatever reason, nobody would
have the resources to continue with the backport. Do you know what
Raphael's response to that was?
| If I disappear and nobody else is willing to maintain 1.8.x, you
| can just backport 1.10.x from stretch into jessie-backports and you
| will be fine.
So let's say even if Rhonda and Alexander decide to let Django 1.8
stay in backports for now, you are still relying on something that
could change at any moment, should Raphael become unavailable. And
while I can't speak for the release team, I seriously doubt that they
would approve of any transition plan like this.
>> [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.
I'm not talking about NEWS.Debian, I'm talking about the official
release notes. There's currently a bug open against the
release-notes, opened by someone who read _this specific thread_,
to document this issue. Not by any maintainer of any of the
affected packages.
> Within LAVA we have comprehensive documentation and we include in that
> the process of installing updates via backports.
Sure, upstream documentation that does NOT come with the current
package in Jessie (how could it?) and the user has to read that
before upgrading, or they potentially loose data.
So to recap:
- You did NOT communicate this issue to the release team at all.
- The Django maintainers also appear not to have been informed,
as Raphael clearly stated in this thread that it's the first
time he's heard about this problem.
- You made NO effort to update Debian's release notes.
- There is NO kind of mechanism in place to prevent a direct
upgrade in some preinst script in order to make sure users
don't accidentally loose data. (This would probably have to
be coordinated with the Django maintainers, because it
probably won't be sufficient to put it in lava-server's
preinst.)
- By sheer coincidence backports ftpmasters rejected a package
you depended upon and that's the only reason this issue has
been given a bit of spotlight at all.
- Had this issue not come up until the time Stretch will be
released, a user of lava-server from Debian Jessie without
backports could have easily LOST DATA during an upgrade,
even when following all best practices for Debian upgrades.
I really don't know what to say here...
Regards,
Christian
Reply to: