qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Wainer dos Santos Moschetta <wainersm@redhat.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, rth@twiddle.net, ehabkost@redhat.com,
	crosa@redhat.com, ccarrara@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] target/i386: Fixes to the check missing features routine
Date: Tue, 11 Dec 2018 11:15:32 -0600	[thread overview]
Message-ID: <b75eb4c9-17dc-9311-d569-d2a8772b2ef3@redhat.com> (raw)
In-Reply-To: <20181211162846.31149-1-wainersm@redhat.com>

On 12/11/18 10:28 AM, Wainer dos Santos Moschetta wrote:
> The x86_cpu_class_check_missing_features() returns a list
> of unavailable features compared to the host CPU. Currently it may
> return empty strings for unnamed features as well as duplicated
> names.
> 
> For example, the qmp "query-cpu-definitions" below shows one empty
> string and repeated "mpx" entries:
> 

> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>

Careful. While I spotted typos in v1,...

> Reviewed-by: Caio Carrara <ccarrara@redhat.com>
> ---
> v2:
>   * Fixed typos. [eblake]

...and you indeed addressed them, me pointing out typos does not imply 
that I reviewed the patch for correctness.  In fact, I specifically did 
NOT give my R-by: tag to v1, because I'm not (yet?) familiar enough with 
the tests/acceptance/ framework to state that I have fully reviewed the 
patch for correctness; instead, I'm comfortable relying on the reviews 
of others (and I am again intentionally not giving R-by to v2).

Also, when posting a v2, you should include the R-by actually given to 
v1 only if the patch is roughly the same as the original.  Fixing minor 
issues that a reviewer pointed out, or doing obvious rebasing to changes 
applied earlier in the series or on upstream git, but where the 
algorithm of the patch itself did not change, is okay for keeping R-b 
(so if I _had_ given R-b, and your spelling changes were the only 
difference, then keeping my R-b would make sense); but where the patch 
is fundamentally different, such as:

>  * Removed unwanted manual test case. [ccarrara, ehabkost]
>  * Not passing 'accel=kvm' on test's VM. [ehabkost]

then omitting ALL R-by tags, in order to ensure that reviewers check 
that the new patch is still correct, is a wiser course of action.  Yes, 
this is more of a rule of thumb, and there are cases where keeping or 
dropping R-b is more of an art form than an exact science; but hopefully 
this helps you understand how the tag can be useful for iterative reviews.

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

  reply	other threads:[~2018-12-11 17:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 16:28 [Qemu-devel] [PATCH v2] target/i386: Fixes to the check missing features routine Wainer dos Santos Moschetta
2018-12-11 17:15 ` Eric Blake [this message]
2018-12-11 19:47   ` Wainer dos Santos Moschetta
2018-12-11 19:58     ` Eric Blake
2018-12-12  1:32 ` Eduardo Habkost

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=b75eb4c9-17dc-9311-d569-d2a8772b2ef3@redhat.com \
    --to=eblake@redhat.com \
    --cc=ccarrara@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=wainersm@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 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).