All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"John Snow" <jsnow@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Claudio Fontana" <cfontana@suse.de>
Subject: Re: [RFC PATCH] docs/about/build-platforms: Refine the distro support policy
Date: Fri, 17 Feb 2023 14:59:49 +0000	[thread overview]
Message-ID: <Y++WZfJUC8B/fUKr@redhat.com> (raw)
In-Reply-To: <3b6b4035-0a7b-431e-6479-70753f850554@redhat.com>

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 <thuth@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-pbonzini@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 :|



  reply	other threads:[~2023-02-17 15:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 13:26 [RFC PATCH] docs/about/build-platforms: Refine the distro support policy Thomas Huth
2023-02-17 14:44 ` Paolo Bonzini
2023-02-17 14:59   ` Daniel P. Berrangé [this message]
2023-02-17 15:06 ` Daniel P. Berrangé
2023-02-17 18:30   ` Thomas Huth
2023-02-20  9:21     ` Markus Armbruster
2023-02-17 15:55 ` Markus Armbruster
2023-02-17 15:59   ` Daniel P. Berrangé
2023-02-17 18:47     ` Thomas Huth
2023-02-17 20:17       ` Paolo Bonzini
2023-02-20  9:26         ` Markus Armbruster
2023-02-20  9:39       ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y++WZfJUC8B/fUKr@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=cfontana@suse.de \
    --cc=jsnow@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.