From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel@nongnu.org,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Cc: 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 12:02:55 +0200 [thread overview]
Message-ID: <9d132b19-0ca7-409c-995a-4fac96b78799@redhat.com> (raw)
In-Reply-To: <e0e836cf-f080-45f4-a71b-060dd2c90279@linaro.org>
On 30/04/2024 11.40, 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).
My thinking was like this:
1) We recently talked about marking all machine types up to 2.12 as
deprecated recently. 2.12 has been released in 2018, so if we feel confident
that those old machine types could go away now/soon, 2024 - 2018 = 6 years
seem to be a good rule of thumb.
2) RHEL and OpenSuSE tend to provide feature updates in their enterprise
distros for 5 (RHEL) or 6 (current OpenSuSE AFAIK) years, so keeping old
machine types in upstream QEMU for that amount of time certainly also helps
with downstream distros.
>> 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?
If I put 9.1 now there, that would make it possible to immediately remove
machines in 9.2, i.e. we would skip the
must-be-marked-as-deprecated-for-two-releases rule here.
Thomas
next prev parent reply other threads:[~2024-04-30 10:04 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é
2024-04-30 10:02 ` Thomas Huth [this message]
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=9d132b19-0ca7-409c-995a-4fac96b78799@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).