From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJWC-0001VH-2s for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:11:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgJW7-0000XU-V6 for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:11:52 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:33561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJW7-0000XQ-NZ for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:11:47 -0500 Received: by ggnk1 with SMTP id k1so10208450ggn.4 for ; Thu, 29 Dec 2011 09:11:47 -0800 (PST) Message-ID: <4EFC9F50.7030205@codemonkey.ws> Date: Thu, 29 Dec 2011 11:11:44 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EEF70B4.3070109@us.ibm.com> <4EF73EF5.8050606@redhat.com> <4EF88EC0.8020301@codemonkey.ws> <4EF8FC88.70809@redhat.com> <4EFA4829.4000207@redhat.com> <4EFA80EA.3050405@codemonkey.ws> <4EFAA2A2.4000107@redhat.com> <4EFB2764.7040006@codemonkey.ws> <4EFB2F36.2090408@redhat.com> <4EFB46DD.4000905@codemonkey.ws> <4EFB5014.9030609@redhat.com> <4EFC7B72.9050802@redhat.com> <4EFC97C3.4080603@codemonkey.ws> <4EFC9AFF.5070707@redhat.com> <4EFC9D2B.1020606@codemonkey.ws> <4EFC9E2E.6080806@redhat.com> In-Reply-To: <4EFC9E2E.6080806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "lmr@redhat.com" , Stefan Hajnoczi , cleber@redhat.com, dlaor@redhat.com, qemu-devel , Gerd Hoffmann , Cleber Rosa On 12/29/2011 11:06 AM, Avi Kivity wrote: > On 12/29/2011 07:02 PM, Anthony Liguori wrote: >> >> Those are rare occurrences and have always been a bit awkward. OTOH, >> we're talking about the critical path of essentially every single >> feature that gets merged into QEMU. >> > > Won't that be qtest? The difference is that the qtest test can be patch N/N in a patch series and be merged at exactly the same time. I think having an in-tree test suite is the only practical way to do TDD. Regards, Anthony Liguori >>> Let's consider postcopy live migration being proposed. In addition to >>> various unit tests, it also wants an integration test. So now we need >>> to write a qemu-test postcopy live migration test, and also autotest >>> test that tests non-Linux guests, migration under load, with memory >>> hotplug, etc. >> >> But the integration test is also going to depend on libvirt support >> for the feature. So how does this all get orchestrated? kvm-autotest >> merges the test case first, then QEMU merges the support, then >> libvirt? What about VDSM and ovirt-engine? Once kvm-autotest starts >> supporting VDSM that's yet another component to deal with. >> >> Realistically, kvm-autotest is going to have to wait for the bits to >> get merged in all of the necessary pieces and then build a test for it >> on their own schedule. > > It just has to be posted and reviewed, it doesn't all have to be merged > at the same time (and the qemu merge has to precede the autotest merge) >