All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: David Marchand <david.marchand@6wind.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, pbonzini@redhat.com,
	claudio.fontana@huawei.com, jani.kokkonen@huawei.com,
	cam@cs.ualberta.ca, armbru@redhat.com, stefanha@gmail.com,
	arei.gonglei@huawei.com
Subject: Re: [PATCH v4 00/14] ivshmem: update documentation, add client/server tools
Date: Wed, 03 Sep 2014 08:47:34 -0600	[thread overview]
Message-ID: <54072A06.50101@redhat.com> (raw)
In-Reply-To: <54071135.30100@6wind.com>

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 09/03/2014 07:01 AM, David Marchand wrote:

>> Rather than introducing new files with bugs, followed by patches to
>> clean it up, why not just introduce the new files correct in the first
>> place?  I think you are better off squashing in a lot of the cleanup
>> patches into patch 1.
> 
> Actually, I mentioned this in a previous email but did not get any comment.
> So, I preferred to send the splitted patches to ease review (from my
> point of view).

It does not ease reviewer time to have a known buggy patch with later
cleanups.  I'd rather see your best effort at a bug-free patch to begin
with, than to spend my time pointing out bugs only to find out you
already fixed them later in the series.

> 
> Once code looks fine enough, I intend to keep only three patches :
> - one for the initial import of ivshmem-client / server
> - one for the documentation update
> - one last with the protocol change

If that is your plan for the final series, then that is the same plan
you should be using for reviews.  You want the reviewers to see your
proposed final product, not your intermediate state of how you got there.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: David Marchand <david.marchand@6wind.com>
Cc: kvm@vger.kernel.org, stefanha@gmail.com,
	claudio.fontana@huawei.com, qemu-devel@nongnu.org,
	armbru@redhat.com, arei.gonglei@huawei.com, pbonzini@redhat.com,
	jani.kokkonen@huawei.com, cam@cs.ualberta.ca
Subject: Re: [Qemu-devel] [PATCH v4 00/14] ivshmem: update documentation, add client/server tools
Date: Wed, 03 Sep 2014 08:47:34 -0600	[thread overview]
Message-ID: <54072A06.50101@redhat.com> (raw)
In-Reply-To: <54071135.30100@6wind.com>

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 09/03/2014 07:01 AM, David Marchand wrote:

>> Rather than introducing new files with bugs, followed by patches to
>> clean it up, why not just introduce the new files correct in the first
>> place?  I think you are better off squashing in a lot of the cleanup
>> patches into patch 1.
> 
> Actually, I mentioned this in a previous email but did not get any comment.
> So, I preferred to send the splitted patches to ease review (from my
> point of view).

It does not ease reviewer time to have a known buggy patch with later
cleanups.  I'd rather see your best effort at a bug-free patch to begin
with, than to spend my time pointing out bugs only to find out you
already fixed them later in the series.

> 
> Once code looks fine enough, I intend to keep only three patches :
> - one for the initial import of ivshmem-client / server
> - one for the documentation update
> - one last with the protocol change

If that is your plan for the final series, then that is the same plan
you should be using for reviews.  You want the reviewers to see your
proposed final product, not your intermediate state of how you got there.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

  reply	other threads:[~2014-09-03 15:49 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 15:25 [PATCH v4 00/14] ivshmem: update documentation, add client/server tools David Marchand
2014-09-02 15:25 ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 01/14] contrib: add ivshmem client and server David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 20:20   ` Eric Blake
2014-09-02 20:20     ` [Qemu-devel] " Eric Blake
2014-09-02 15:25 ` [PATCH v4 02/14] docs: update ivshmem device spec David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 20:24   ` Eric Blake
2014-09-02 20:24     ` [Qemu-devel] " Eric Blake
2014-09-02 15:25 ` [PATCH v4 03/14] contrib/ivshmem-*: comply with QEMU coding style David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 04/14] contrib/ivshmem-*: reuse qemu/queue.h David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 05/14] contrib/ivshmem-*: switch to QEMU headers David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 20:28   ` Eric Blake
2014-09-02 20:28     ` [Qemu-devel] " Eric Blake
2014-09-02 15:25 ` [PATCH v4 06/14] contrib/ivshmem-server: set client sockets as non blocking David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 07/14] contrib/ivshmem-*: add missing const and static attrs David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 08/14] contrib/ivshmem-*: plug client and server in QEMU top Makefile David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 09/14] contrib/ivshmem-*: switch to g_malloc0/g_free David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 10/14] contrib/ivshmem-server: fix mem leak on error David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 11/14] contrib/ivshmem-*: rework error handling David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 12/14] contrib/ivshmem-*: various fixes David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 13/14] contrib/ivshmem-server: align server default parameter values David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 15:25 ` [PATCH v4 14/14] ivshmem: add check on protocol version in QEMU David Marchand
2014-09-02 15:25   ` [Qemu-devel] " David Marchand
2014-09-02 20:31 ` [PATCH v4 00/14] ivshmem: update documentation, add client/server tools Eric Blake
2014-09-02 20:31   ` [Qemu-devel] " Eric Blake
2014-09-03 13:01   ` David Marchand
2014-09-03 13:01     ` [Qemu-devel] " David Marchand
2014-09-03 14:47     ` Eric Blake [this message]
2014-09-03 14:47       ` Eric Blake

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=54072A06.50101@redhat.com \
    --to=eblake@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=armbru@redhat.com \
    --cc=cam@cs.ualberta.ca \
    --cc=claudio.fontana@huawei.com \
    --cc=david.marchand@6wind.com \
    --cc=jani.kokkonen@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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.