From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7PoI-0007CT-V7 for qemu-devel@nongnu.org; Fri, 11 Dec 2015 10:40:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a7PoF-0007N8-AJ for qemu-devel@nongnu.org; Fri, 11 Dec 2015 10:40:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7PoF-0007Mm-45 for qemu-devel@nongnu.org; Fri, 11 Dec 2015 10:40:39 -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> <566ADE90.3070303@redhat.com> <20151211145547.GA4029@var.bordeaux.inria.fr> <566AE733.4040408@redhat.com> From: Laszlo Ersek Message-ID: <566AEE70.6060600@redhat.com> Date: Fri, 11 Dec 2015 16:40:32 +0100 MIME-Version: 1.0 In-Reply-To: <566AE733.4040408@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/18] slirp: Generalizing and neutralizing code before adding IPv6 stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth , Samuel Thibault Cc: zhanghailiang , Li Zhijian , Stefan Hajnoczi , Jason Wang , qemu-devel@nongnu.org, Vasiliy Tolstov , Dave Gilbert , Gonglei , Jan Kiszka , Huangpeng , Guillaume Subiron meta On 12/11/15 16:09, Thomas Huth wrote: > On 11/12/15 15:55, Samuel Thibault wrote: >> Thomas Huth, on Fri 11 Dec 2015 15:32:48 +0100, wrote: >>> 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. >> >> Ok, that's what we already have: patches 1-9 are refactoring and >> support, and 10-18 are ipv6 code. > > Sounds good, ... then I'd suggest to sent the preparation patches > separately next time and get them accepted first. And then the next reviewer will say, "nice, but it would be even nicer to see what *motivates* these preparatory patches!" :) Disclaimer: I don't have any technical context for this thread; I just noticed Samuel's email / frustration. I know that all too well, first hand, from this list and elsewhere. I don't know how it can be fixed, but I'm positive it is a *systemic* problem with this development model. (I didn't contribute much value with this email, but perhaps Samuel will feel better by seeing some (however unsolicited) confirmation; plus hey it's Friday.) Thanks Laszlo