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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Feb 17, 2023 at 04:55:49PM +0100, Markus Armbruster wrote:
> 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?

I think my response covers the reasons why not. In summary

The cost/benefit tradeoff of mandating a new python runtime is
quite favourable, as the the distro vendor still provids the
python runtime, and so only cost is pip installation which is
largely eliminated if we have QEMU auto-create a virtualenv.

The cost/benefit tradeoff of dropping the platforms entirely
is not obviously favourable when we don't have clear demand
to bump the min versions of native packages, and the cost to
users stuck on these platforms to build their own toolchain
or libraries is very high.

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 :|