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

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> 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

"one year" (singular)

Suggest "the next major version".

> +or when the vendor itself drops support, whichever comes first.
> +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

If we take Paolo's "[RFC PATCH] docs: build-platforms: refine
requirements on Python build dependencies", then the rationale for this
one becomes weaker.  But I believe it's well worth serious consideration
all the same.

Why would we *not* want to do what Thomas proposes?