qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/1] qmp: marking qmp_cpu as deprecated


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 1/1] qmp: marking qmp_cpu as deprecated
Date: Tue, 19 Dec 2017 06:51:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 12/19/2017 06:19 AM, Daniel Henrique Barboza wrote:

Let's compare behavior:

0. Status quo                       do nothing and succeed
1. Your patch                       fail with GenericError
2. Your patch less error_setg()     do nothing and succeed
3. Immediate removal                fail with CommandNotFound

Does the difference between 1. and 3. matter at all?  Or is it just
deprecation cargo cult?

Good point. If both the deprecation message and the removal will
result in error for the user ....


Here's my take on it.  I'd prefer 3. Immediate removal.  I'd also be
fine with 2. Your patch less error_setg(), followed by removal after the
customary deprecation period.  1. plus later removal just doesn't make
sense to me, but it's really no big deal, so if you guys want it...

It all goes down to whether we consider qmp_cpu, a QMP command that does
nothing since its creation and apparently no one ever used it, a feature. If it's a feature, then I vote for (2) and removal after 2 releases following the regular
deprecation policy.

If we consider that applying the policy to qmp_cpu is more trouble than it's worth, I'll gladly resend this patch removing it entirely and rewording the qemu-doc.texi
entry to mention that it was removed because it did nothing and it was of
no use for anyone.


My vote: (3). No one was using qmp_cpu for anything, while deprecation exists to allow a user a chance to fix their workflow to adjust from one thing that works (but badly) to its replacement that also works (and will be supported long term). Since our replacement is nothing, we are admitting that no one was relying on the command, and I don't see the point in a deprecation delay. Just nuke it!

qemu-doc.texi doesn't even need to mention the command; the commit message is enough to document our reasons for complete removal.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]