On Fri, Feb 17, 2023 at 03:44:23PM +0100, Paolo Bonzini wrote: > On 2/17/23 14:26, Thomas Huth wrote: > > 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 <th...@redhat.com> > > This has the advantage of being a very simple change to the support policy. > However, it has the disadvantage that at this point both SLE15 and RHEL8 are > not hard to support _at run-time_, only the build is a bit problematic; so, > it kinda throws away the baby with the bathwater.
I think it could be a little fuzzy. I agree if thinking about QEMU.git in isolation. If we consider that python-qemu-qmp.git is conceptually positioned as a general purpose QEMU python client, that would extend to runtime support. We could define a separate support policy for python-qemu-qmp.git, but if we're intending to delete the in-tree python QMP code and use python-qemu-qmp.git directly, then its support policy does interact with qemu.git. > I have posted another RFC at > https://lore.kernel.org/qemu-devel/20230217124150.205012-1-pbonz...@redhat.com; > they share the 4 year deadline but it only applies to non-native > dependencies (which means Python right now). > > Thanks for posting this, it's useful to have two different possibilities to > compare. > > Paolo > > > --- > > 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. > > +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 :|
