All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com,
	Bulent Abali <abali@us.ibm.com>,
	Michael R Hines <mrhines@us.ibm.com>,
	Gokul B Kandiraju <gokul@us.ibm.com>,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 00/12] rdma: migration support
Date: Tue, 23 Apr 2013 16:15:37 -0400	[thread overview]
Message-ID: <5176EBE9.3080204@linux.vnet.ibm.com> (raw)
In-Reply-To: <5176DFFD.1040202@redhat.com>

On 04/23/2013 03:24 PM, Eric Blake wrote:
> On 04/23/2013 12:26 PM, Anthony Liguori wrote:
>>> There are no instructions/procedures documented on the qemu.org
>>> website on how to automatically generate "Reviewed-by" signatures.
>> I suspect there's some confusion here.  Addressed review comments !=
>> Reviewed-by.  There can always be additional comments.  Someone has to
>> explicitly offer a Reviewed-by indicating that they are happy with the
>> patches overall.  I've gone through the history on these patches and I
>> don't see any explicit Reviewed-by's other than Eric's most recent one.
> Even then, my reviewed-by tag applied only to one patch (the QMP change)
> rather than the series as a whole.  But you definitely did the right
> thing by pasting that in to the commit message of 10/12 on this round -
> even though it is a bit of manual effort on your part, you were already
> touching the rest of the series; and by adding the reviewed-by tag by
> hand, it's easier for other reviewers to add additional reviews and/or
> skip the patches that appear to already be adequately reviewed.
>
>> Give the series a little more time for people to look over it, it'll get
>> Reviewed-bys when people are ready to offer them.
> And to some extent, it's up to the maintainer of the area you are
> touching to decide how many (or few) 3rd-party reviewed-by are necessary
> to feel comfortable with the series.  Most maintainers like at least one
> other set of eyes looking at any non-trivial patch, although I'm not
> sure if there are any documented policies used by any particular
> maintainer (other than qemu-trivial patches have their own wiki page for
> best practices).  So far, your series has been a good cycle of posting,
> response, and updating to meet the response; the fact that you are
> getting comments from several people means that you are likely to get
> reviewed-by from those people when they are happy with the end result
> (or another round of comments on things to fix).  And if all else fails,
> if you go a week without any response at all, it is generally acceptable
> to ping the maintainer to ask for help in recruiting the appropriate
> reviewers and/or a decision that the maintainer's review is sufficient.
>
> Also, don't be surprised if not everyone reviews the entire series;
> sometimes reviewers like myself focus only on the portion of the series
> that interacts with my current interests (I tend to review anything QMP,
> because I want to make sure the design will be sane for libvirt
> interaction, while overlooking things like migration internals because
> they are black box ops to libvirt if the interface was sane).
>

Yes, Paolo has done a fantastic job of reviewing the internals.

Thanks for the advice. I don't mind waiting until 1.6.

Would be helpful for new people (like myself) to have a summary
of these procedures on the wiki so we don't have to bother you
guys when we get to the end of the reviews.

- Michael

  reply	other threads:[~2013-04-23 20:15 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-23  1:55 [Qemu-devel] [PATCH v5 00/12] rdma: migration support mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 01/12] rdma: add documentation mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 02/12] rdma: export yield_until_fd_readable() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 03/12] rdma: export throughput w/ MigrationStats QMP mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 04/12] rdma: introduce qemu_get_max_size() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 05/12] rdma: introduce qemu_file_mode_is_not_valid() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 06/12] rdma: export qemu_fflush() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 07/12] rdma: introduce ram_handle_compressed() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 08/12] rdma: introduce qemu_ram_foreach_block() mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 09/12] rdma: new QEMUFileOps hooks mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 10/12] rdma: introduce capability x-rdma-pin-all mrhines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 11/12] rdma: core logic mrhines
2013-04-23 20:59   ` Paolo Bonzini
2013-04-23 23:53     ` Michael R. Hines
2013-04-24  6:38       ` Paolo Bonzini
2013-04-24 18:19         ` Michael R. Hines
2013-04-23 21:10   ` Paolo Bonzini
2013-04-24  0:01     ` Michael R. Hines
2013-04-23  1:55 ` [Qemu-devel] [PATCH v5 12/12] rdma: send pc.ram mrhines
2013-04-23 17:50 ` [Qemu-devel] [PATCH v5 00/12] rdma: migration support Anthony Liguori
2013-04-23 17:54   ` Michael R. Hines
2013-04-23 18:26     ` Anthony Liguori
2013-04-23 18:46       ` Michael R. Hines
2013-04-23 18:55         ` Anthony Liguori
2013-04-23 19:24       ` Eric Blake
2013-04-23 20:15         ` Michael R. Hines [this message]
2013-04-23 21:11           ` Eric Blake
2013-04-23 21:44             ` Anthony Liguori
2013-04-23 22:40               ` [Qemu-devel] contribution process [was: [PATCH v5 00/12] rdma: migration support] Eric Blake
2013-04-23 23:50                 ` Michael R. Hines
2013-04-23 23:50               ` [Qemu-devel] [PATCH v5 00/12] rdma: migration support Michael R. Hines
2013-04-23 21:11           ` Paolo Bonzini
2013-04-23 23:49             ` Michael R. Hines
2013-04-23 20:16       ` Michael R. Hines
  -- strict thread matches above, loose matches on Subject: below --
2013-04-21 21:17 mrhines

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=5176EBE9.3080204@linux.vnet.ibm.com \
    --to=mrhines@linux.vnet.ibm.com \
    --cc=abali@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=gokul@us.ibm.com \
    --cc=mrhines@us.ibm.com \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.