From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQyTN-0006ET-R8 for qemu-devel@nongnu.org; Fri, 21 Mar 2014 08:22:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQyTH-0002kT-Nd for qemu-devel@nongnu.org; Fri, 21 Mar 2014 08:22:53 -0400 Received: from mail-oa0-f47.google.com ([209.85.219.47]:57058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQyTH-0002kH-JO for qemu-devel@nongnu.org; Fri, 21 Mar 2014 08:22:47 -0400 Received: by mail-oa0-f47.google.com with SMTP id i11so2410311oag.6 for ; Fri, 21 Mar 2014 05:22:46 -0700 (PDT) Date: Fri, 21 Mar 2014 12:21:28 +0000 From: Leandro Dorileo Message-ID: <20140321122128.GA18432@dorilex> References: <1394436721-21812-1-git-send-email-cyliu@suse.com> <20140321000705.GA17339@dorilex> <20140321103453.GB3091@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140321103453.GB3091@noname.redhat.com> Subject: Re: [Qemu-devel] [PATCH v22 00/25] replace QEMUOptionParameter with QemuOpts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Chunyan Liu , stefanha@redhat.com, qemu-devel@nongnu.org Hi Kevin, On Fri, Mar 21, 2014 at 11:34:53AM +0100, Kevin Wolf wrote: > Am 21.03.2014 um 01:07 hat Leandro Dorileo geschrieben: > > Hi Chunyan, > > > > On Mon, Mar 10, 2014 at 03:31:36PM +0800, Chunyan Liu wrote: > > > This patch series is to replace QEMUOptionParameter with QemuOpts, so that only > > > one Qemu Option structure is kept in QEMU code. > > > > > > > > > Last night I took some time do take a deeper look at you series and the required > > effort to do the QemuOptionParameter -> QemuOpts migration. > > > > I think you've over complicated the things, I understand you tried to keep your > > serie's bisectability (?), but the final result was something really hard to > > review and to integrate as well. The overall approach wasn't even resolving the > > bisectability problem since it breaks the tree until the last commit. Moreover, > > in the path of getting things ready you created new problems and their respective > > fixes, what we really don't need to. > > > > In this regards you could have kept things as simple as possible and submitted > > the patches in a "natural way", even if they were breaking the build between each > > patch, you could get all the required maintainer's Reviewed-by + Tested-by + > > Signed-off-by and so on for each individual patch and when it was time to > > integrate get squashed the needed patches. > > No, please not. If you have bisectability on the surface, but the bisect > ends in a monster patch with several thousand lines of code, nothing is > won. I don't think that is the case (several thousand lines), with the experiment I did the "squashable" patches are 769 insertions(+), 1076 deletions(-), of course, the patch series is bigger than that - not that bigger, but bigger - but I'm mentioning only the patches I think need to be squashed. These patches represent the changes across the block layer. I see no gain on increasing the patches complexity just to avoid a patch with that statistic. More over, the changes are very simple and easily reviewable. Regards... -- Leandro Dorileo