qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, "Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/1] qmp: marking qmp_cpu as deprecated
Date: Tue, 19 Dec 2017 06:51:54 -0600	[thread overview]
Message-ID: <caa98406-154a-a599-6556-5b6ef13d4d25@redhat.com> (raw)
In-Reply-To: <a4277edc-37f6-8673-1883-b30f793d9d43@linux.vnet.ibm.com>

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	other threads:[~2017-12-19 12:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 18:44 [Qemu-devel] [PATCH v2 0/1] deprecate qmp_cpu Daniel Henrique Barboza
2017-12-18 18:44 ` [Qemu-devel] [PATCH v2 1/1] qmp: marking qmp_cpu as deprecated Daniel Henrique Barboza
2017-12-18 19:02   ` Daniel P. Berrange
2017-12-19 10:12   ` Markus Armbruster
2017-12-19 12:19     ` Daniel Henrique Barboza
2017-12-19 12:51       ` Eric Blake [this message]

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=caa98406-154a-a599-6556-5b6ef13d4d25@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=danielhb@linux.vnet.ibm.com \
    --cc=qemu-devel@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).