On Tue, 16 Jul 2019 at 18:48, Aleksandar Markovic
<aleksandar.m.m...@gmail.com> wrote:
> "For distributions with frequent, short-lifetime releases, the project will
> aim to support all versions that are not end of life by their respective
> vendors. For the purposes of identifying supported software versions,
> the project will look at Fedora, Ubuntu, and openSUSE distros. Other
> short-lifetime distros will be assumed to ship similar software versions.
>
> For distributions with long-lifetime releases, the project will aim to
> support the most recent major version at all times. Support for the
> previous major version will be dropped 2 years after the new major
> version is released. For the purposes of identifying supported software
> versions, the project will look at RHEL, Debian, Ubuntu LTS, and
> SLES distros. Other long-lifetime distros will be assumed to ship
> similar software versions."
>
> However, any distribution is a "living creature". Packages are constantly
> added and modified, and Ubuntu 16.04 looks different at its inception
> and now, even though it bears the same version number, 16.04.

Ubuntu do actually put a sub-version number in here; if you
do 'lsb_release -a' on a properly upgraded 16.04 LTS system
it will tell you it's 16.04.6.

> The problem here (not directly visible from the policy) is that it looks
> as if we implicitly assume that any end user is constantly updating and
> upgrading their systems - and that may not be true.

We do effectively assume that to some extent (ie I don't
think we need to support the very first 16.04 release), and
I think that's not unreasonable, because if you're not updating
then you have a huge pile of security vulnerabilities you haven't
patched against. The vastly common use case is to stay up to date
within an LTS type release.

> I think we can't say
> to such user: "Why didn't you update your Ubuntu 16.04?" It is up to the
> user how he/she wants to use their OS, we can't and shouldn't dictate
> that - at least this is my understanding of our desired relations to the
> end users.

We don't dictate to users how they should use or update their
OS. But we do have to define a policy which balances the
amount of effort we as upstream would have to do (limiting
the set of systems we support is less work for us), against
the benefit to users of having support for a wider range of
systems. The deprecation-policy is where we've set that balance.
It is inevitable that there will be some set of users that are
left unsupported by the point we've chosen. We hope that that
set of users is fairly small, because we include LTS distros
in our supported set and give a 2 year grace period for users
to move forward; and many users who for stability reasons want
to stick with an older distro will also be staying with the
older QEMU and not moving forward to the most recent one.
But, yes, there will be some who are stuck on the older LTS and
still want the newer QEMU. That's unfortunate for them, but
we can't support everybody on the planet on every version of
Linux ever shipped since the 1990s. Those users get to
make a choice between remaining with their stable environment
(the QEMU we shipped to them originally still works and won't
evaporate) or moving forward to both a newer QEMU and perhaps
a newer version of their host OS.

thanks
-- PMM

Reply via email to