qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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




  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).