Comment 34 for bug 1717040

On Tue, Jan 16, 2018 at 07:37:15PM -0000, Graham Inggs wrote:
> "...an application hardwired to deal with v0.5.x experimental format, if
> such a thing exist..."
>
> @ahasenack: Isn't this precisely we have Ubuntu Backports?

I think we're somewhere in the middle.

AIUI, virtually nothing else in the wider ecosystem can consume output
produced by Xenial's zstd CLI tool. By publishing an update into
xenial-updates, we'd be recommending that users update to it
automatically (in practice the majority will get it without taking a
separate step) because the version released with Xenial is effectively
broken in terms of interoperability.

> you need to opt-in to install it

The point of considering an SRU for this fix, rather than backports, is
precisely to remove this requirement. Users expect broken stuff to be
fixed without having to individually opt-in to each fix, but instead by
installing general "updates".

I can see how this particular proposed update could go either way. But
right now, we seem to be swinging in the direction of releasing it as an
SRU, especially because we have a way to do that with no known downside.
Our existing SRU policy does permit an update as a result of a change in
the wider Internet environment. That we have an interop problem because
the zstd CLI produces output that can't practically be handled anywhere
else does, IMHO, qualify it for an SRU under this existing policy
permission. The question is if and how we do it in the face of
regression risk to existing users.

Comments welcome, but please frame the discussion in terms of what we're
trying to do and in terms of our existing SRU policy documented at
https://wiki.ubuntu.com/StableReleaseUpdates.