From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
devel@lists.libvirt.org, "Alex Bennée" <alex.bennee@linaro.org>,
"Laurent Vivier" <laurent@vivier.eu>,
qemu-s390x@nongnu.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
"Peter Xu" <peterx@redhat.com>, "Fabiano Rosas" <farosas@suse.de>
Subject: Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years
Date: Tue, 30 Apr 2024 10:58:44 +0100 [thread overview]
Message-ID: <ZjDA1BFQwo19FLam@redhat.com> (raw)
In-Reply-To: <e0e836cf-f080-45f4-a71b-060dd2c90279@linaro.org>
On Tue, Apr 30, 2024 at 11:40:42AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
>
> On 30/4/24 08:45, Thomas Huth wrote:
> > Old machine types often have bugs or work-arounds that affect our
> > possibilities to move forward with the QEMU code base (see for example
> > https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
> > cannot be fixed without breaking live migration with old machine types,
> > or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
> > commit ea985d235b86). So instead of going through the process of manually
> > deprecating old machine types again and again, let's rather add an entry
> > that can stay, which declares that machine types older than 6 years are
> > considered as deprecated automatically. Six years should be sufficient to
> > support the release cycles of most Linux distributions.
>
> Thanks for taking that out of my plate :)
>
> IIRC 6 years was because of some old RHEL version, otherwise could
> 5 years be enough? (maybe it could be good enough for this old RHEL
> version as of QEMU v10.0).
With my RHEL hat on, 6 years gives an approximate alignment with
RHEL lifecycles, which have ended up being roughly 3 years apart.
RHEL-N, wants to support all machine types from RHEL-(N-1), so
in the worst case that gives up to 6 years worth of QEMU versions.
5 years could well be enough in many cases, depending on how
frequently RHEL rebases QEMU, but could also trip us up if the
timelines do something unexpected. So 6 years is a bit safer
from Red Hat's POV, if the community is willing.
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> > docs/about/deprecated.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 6d595de3b6..fe69e2d44c 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone noticing.
> > System emulator machines
> > ------------------------
> > +Versioned machine types older than 6 years
> > +''''''''''''''''''''''''''''''''''''''''''
> > +
> > +Starting with the release of QEMU 10.0, versioned machine types older than
>
> Why can't we start with QEMU 9.1?
>
> > +6 years will automatically be considered as deprecated and might be due to
> > +removal without furthor notice. For example, this affects machine types like
> > +pc-i440fx-X.Y, pc-q35-X.Y, pseries-X.Y, s390-ccw-virtio-X.Y or virt-X.Y where
> > +X is the major number and Y is the minor number of the old QEMU version.
> > +If you are still using machine types from QEMU versions older than 6 years,
> > +please update your setting to use a newer versioned machine type instead.
>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
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 :|
next prev parent reply other threads:[~2024-04-30 9:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 6:45 [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years Thomas Huth
2024-04-30 9:32 ` Peter Maydell
2024-04-30 9:40 ` Philippe Mathieu-Daudé
2024-04-30 9:58 ` Daniel P. Berrangé [this message]
2024-04-30 10:02 ` Thomas Huth
2024-04-30 9:45 ` Daniel P. Berrangé
2024-04-30 9:58 ` Cédric Le Goater
2024-04-30 9:55 ` Daniel P. Berrangé
2024-04-30 10:21 ` Daniel P. Berrangé
2024-04-30 10:29 ` Thomas Huth
2024-04-30 16:54 ` 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=ZjDA1BFQwo19FLam@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=devel@lists.libvirt.org \
--cc=farosas@suse.de \
--cc=laurent@vivier.eu \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@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.