From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9iqQ-0005EP-Dc for qemu-devel@nongnu.org; Thu, 28 May 2009 12:52:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9iqL-0005Dp-8B for qemu-devel@nongnu.org; Thu, 28 May 2009 12:52:41 -0400 Received: from [199.232.76.173] (port=49428 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9iqL-0005Dm-3i for qemu-devel@nongnu.org; Thu, 28 May 2009 12:52:37 -0400 Received: from mx2.redhat.com ([66.187.237.31]:60906) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9iqK-0003hV-Lf for qemu-devel@nongnu.org; Thu, 28 May 2009 12:52:36 -0400 From: Mark McLoughlin In-Reply-To: <4A1EB442.1060006@us.ibm.com> References: <1243523971.4046.206.camel@blaa> <4A1EADB4.2060106@us.ibm.com> <1243525873.18588.11.camel@blaa> <4A1EB442.1060006@us.ibm.com> Content-Type: text/plain Date: Thu, 28 May 2009 17:52:27 +0100 Message-Id: <1243529547.18588.32.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:56 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > On Thu, 2009-05-28 at 10:28 -0500, Anthony Liguori wrote: > > > >> 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 used to do that, but not everyone likes it. > > >> 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 :-) > > > > Yes, that's what I was hinting at below :-) > > >> 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 ... > > > > Does kvm-autotest have networking tests? No targeted networking tests yet, no. > I know there's some concern about the time it takes for patches to get > applied. IMHO, the best way to improve that it to get a stronger set of > functional tests. I have a set I've been working on but it's on my > other laptop which I cannot reach ATM :-/ Okay, very interested in seeing that. > As has been discussed before, I'm looking for finer grain functional > tests than the installation tests that kvm-autotest is providing now. > I'm not saying that this series requires submitting a test suite first, > but rather that if you're interested in seeing networking advance more > rapidly, a good investment would be to build out a better test > infrastructure for it. I missed the autotest discussion earlier in the week, just saw it now. Cheers, Mark.