From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58493)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <thuth@redhat.com>) id 1a7Okn-0002Z1-LJ
	for qemu-devel@nongnu.org; Fri, 11 Dec 2015 09:33:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <thuth@redhat.com>) id 1a7Okh-0005dy-QL
	for qemu-devel@nongnu.org; Fri, 11 Dec 2015 09:33:01 -0500
Received: from mx1.redhat.com ([209.132.183.28]:59673)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <thuth@redhat.com>) id 1a7Okh-0005db-Kz
	for qemu-devel@nongnu.org; Fri, 11 Dec 2015 09:32:55 -0500
References: <20151211001505.GV2905@var.home>
	<1449792930-27293-1-git-send-email-samuel.thibault@ens-lyon.org>
	<1449792930-27293-2-git-send-email-samuel.thibault@ens-lyon.org>
	<566AD1E4.1050403@redhat.com> <566AD30E.2060002@redhat.com>
	<566AD45C.20000@redhat.com>
	<20151211140124.GE2927@var.bordeaux.inria.fr>
From: Thomas Huth <thuth@redhat.com>
Message-ID: <566ADE90.3070303@redhat.com>
Date: Fri, 11 Dec 2015 15:32:48 +0100
MIME-Version: 1.0
In-Reply-To: <20151211140124.GE2927@var.bordeaux.inria.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 02/18] slirp: Generalizing and neutralizing
 code before adding IPv6 stuff
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Samuel Thibault <samuel.thibault@gnu.org>, Jan Kiszka <jan.kiszka@siemens.com>
Cc: zhanghailiang <zhang.zhanghailiang@huawei.com>, Li Zhijian <lizhijian@cn.fujitsu.com>, Stefan Hajnoczi <stefanha@gmail.com>, Jason Wang <jasowang@redhat.com>, Dave Gilbert <dgilbert@redhat.com>, Vasiliy Tolstov <v.tolstov@selfip.ru>, qemu-devel@nongnu.org, Gonglei <arei.gonglei@huawei.com>, Huangpeng <peter.huangpeng@huawei.com>, Guillaume Subiron <maethor@subiron.org>

On 11/12/15 15:01, Samuel Thibault wrote:
> Just to explain.
>=20
> I'm fine with revamping the patches, provided that we eventually
> converge somewhere.
>=20
> What I'm afraid of is that splitting patches in yet more many pieces,
> revamping the code yet more (moving code into their own functions, etc.=
)
> will only make the patch series look even bigger and even less prone to
> be included for lack of reviewer time.
>=20
> I agree that the presentation can be looked after. But if that makes th=
e
> patch series much bigger, I'd really prefer to look after that once the
> content gets commited, otherwise I don't see how we'll ever manage to
> get this commited in the coming decade.

Ok, point taken, and I understand your frustration about reworking and
posting this a couple of times without getting the patches accepted.

So maybe it's better to do smaller steps instead: Would it for example
make sense to split the whole series into two parts - first a series
that does all the preparation and cleanup patches. And then once that
has been reviewed and merged, send the second series that adds the real
new IPv6 code.

In the end, it's up to the subsystem mainter how the patches should be
done - so, Jan, what do you think? What way would you recommend to get
the patches ready for being included?

 Thomas