Re: [RFC PATCH] docs/about/build-platforms: Refine the distro support policy

[Daniel P . Berrangé]

On Fri, Feb 17, 2023 at 02:26:31PM +0100, Thomas Huth wrote:
> Our distro support policy has been written with a best-effort
> estimation of what users and developers need. However, as we now
> know, the support for older long-term distributions can get really
> troublesome for upstream development, since it is for example close
> to impossible to keep the code for all Python versions maintained,
> especially if upstream projects dropped support a longer time ago
> already (Python 3.6 has been EOL at the end of 2021) while it is
> still the main version of some long-term distros (CentOS/RHEL 8 and
> openSUSE/SLES 15).
> The QEMU project only has a limited amount of people working on
> the development, so we just cannot afford of supporting both, very
> old and the latest versions of our dependencies without burning
> the few people who are working on those topics. So we *have* to
> refine our support statement instead:
> 
> 1) Once a new major version has been released, it should be enough
> to limit the support for the previous major versions to one year
> instead of two. One year should be enough time to get all people
> who are interested in following the development of QEMU and who would
> like to use the latest and greatest version of QEMU to upgrade their
> system to the next major release of their distribution. All others
> are likely happy with the old version of QEMU that is provided by
> their distributor anyway and thus likely won't try to compile the
> latest and greatest version of QEMU on their system.
> 
> 2) For long-term distributions that release a new version only very
> seldom, we limit the support to four years after the initial release.
> 
> Note: These changes mean that openSUSE is not considered as supported
> anymore (since version 15.0 has been released in May 2018), and
> RHEL/CentOS 8 will not be supported anymore in 3 months (since version
> 8.0 has been released in May 2019).
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  docs/about/build-platforms.rst | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
> index 1c1e7b9e11..cdc38f16a4 100644
> --- a/docs/about/build-platforms.rst
> +++ b/docs/about/build-platforms.rst
> @@ -67,10 +67,11 @@ Non-supported architectures may be removed in the future 
> following the
>  Linux OS, macOS, FreeBSD, NetBSD, OpenBSD
>  -----------------------------------------
>  
> -The project aims 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 or when the vendor itself drops support, whichever comes
> -first. In this context, third-party efforts to extend the lifetime of a 
> distro
> +The project aims to support the most recent major version at all times for
> +up to four years after its initial release. Support for the previous major
> +version will be dropped one years after the new major version is released
> +or when the vendor itself drops support, whichever comes first.


So this change alters the support policy for every dependancy we care
about. IOW, it opens the door to dropping compilers, and many native
libraries too, in addition to the python modules which are the pressing
problem.

I'm not so comfortable with doing the broader approach. RHEL-8 deployments
are still overwhealmingly dominant over RHEL-9, because the kind of people
who deploy enterprise distros don't rush to upgrade to new versions, but
they are interesting as a source of contributors to QEMU.

I'm also not so comfortable dropping the only version of SLES that we
explicitly target, when we don't know when their new major release
will arrive.

If we allow compilers, libraries to be bumped, then someone stuck on
RHEL-8 has a significant task to build their own toolchain/libraries
in order to work with QEMU still. If we only allow python modules to
be bumped, the solution is just a pip install / virtualenv away.

IOW, the cost/benefit tradeoff for bumping python components is
much more favourable that the tradeoff for bumping native components.

> +In this context, third-party efforts to extend the lifetime of a distro
>  are not considered, even when they are endorsed by the vendor (eg. Debian 
> LTS);
>  the same is true of repositories that contain packages backported from later
>  releases (e.g. Debian backports). Within each major release, only the most

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|