From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9ht6-0002ay-Ek for qemu-devel@nongnu.org; Thu, 28 May 2009 11:51:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9ht2-0002a2-Na for qemu-devel@nongnu.org; Thu, 28 May 2009 11:51:24 -0400 Received: from [199.232.76.173] (port=57271 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9ht2-0002Zt-IB for qemu-devel@nongnu.org; Thu, 28 May 2009 11:51:20 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34297) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9ht1-00080b-QQ for qemu-devel@nongnu.org; Thu, 28 May 2009 11:51:20 -0400 From: Mark McLoughlin In-Reply-To: <4A1EADB4.2060106@us.ibm.com> References: <1243523971.4046.206.camel@blaa> <4A1EADB4.2060106@us.ibm.com> Content-Type: text/plain Date: Thu, 28 May 2009 16:51:13 +0100 Message-Id: <1243525873.18588.11.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Networking patches queue Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , qemu-devel On Thu, 2009-05-28 at 10:28 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > Hi Anthony, > > > > Recently, Jan has posted 11 networking patches and I've posted 17, so I > > thought I'd push out a tree with these queued up. Perhaps you want to > > pull from there? > > > > Some notes: > > > > - I've taken the first 6 of Jan's patches, but left 7-11 for now; see > > the review comments I just posted. I expect Jan will be able to > > fix them up fairly quickly > > > > If the first 6 patches of Jan's series are ready to apply, wouldn't it > make sense for him to submit that as a separate series? In the very > least, I'd like an Ack from Jan before applying his series partially. I would have thought that was one of the benefits of a clean, bisectable patch series - that a maintainer could choose to partially apply them. I know when I send a patch series, I'm fully prepared for that to happen and would much rather see them applied partially if possible, rather than re-send the whole series. (Where partially means 1-N not randomly choosing a subset of patches) > > - I've tried my best to fix up the param checking saga by reverting > > Kevin's patch, going with Jan's rollback to something closer to > > what was there originally and applying a small fixup patch > > > > - Not all of these patches are completely isolated to networking > > code - e.g. the fork_exec() patch adds a SIGCHLD handler > > > > - I haven't reviewed the slirp changes in great detail, but they > > look okay at a glance > > > > I just got the tail end of your series before heading off on travel on > Friday. It still needs review and testing. Okay, that's perfectly reasonable. I got the impression you would like (at some point) to be able to have others to act as a funnel for specific areas. I'm just testing the water :-) > Of course, if a patches series included test cases for the functionality > it was implementing, it would certainly go a far way into reducing the > amount of time it took to test those patches :-) That's a funny way of observing "we really should have a networking test suite". Would "this tree passes kvm-autotest's networking tests" help matters? If so, I'm sure that could be organised ... Cheers, Mark.