From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35988 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmlfF-0002tL-3x for qemu-devel@nongnu.org; Tue, 08 Feb 2011 06:23:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmlfC-0007XF-6F for qemu-devel@nongnu.org; Tue, 08 Feb 2011 06:23:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmlfB-0007X5-UZ for qemu-devel@nongnu.org; Tue, 08 Feb 2011 06:23:18 -0500 From: Lucas Meneghel Rodrigues In-Reply-To: References: <9F3B6BB7-4256-4403-A8A8-F91368A98231@suse.de> <1297132183.2738.17.camel@freedom> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 09:23:03 -0200 Message-ID: <1297164183.2603.5.camel@freedom> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Buildbot for qemu.git/master List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Michael Tokarev , Alexander Graf , qemu-devel , Andreas =?ISO-8859-1?Q?F=E4rber?= , gollub@b1-systems.de On Tue, 2011-02-08 at 09:23 +0000, Stefan Hajnoczi wrote: > Public automated qemu.git autotest would be excellent. To be honest I > haven't had much visibility of KVM-Autotest myself as a QEMU/KVM > developer. I suspect many others haven't either but there are big > benefits if we can change this. By running your automated tests on > qemu.git in public we'll catch bugs earlier. > > Do you want to add KVM-Autotest buildslave(s) or are you looking for > something like a HTTP POST notifier that pings you about new qemu.git > HEADs to test? The biggest challenge is to have machines publicly accessible to perform testing, right now we use the machines of our internal laboratory to perform those tests. About notifiers of new git commits, I am unsure whether we should test every and each git commit, since even sanity test takes a while (the typical 84 tests of a sanity job take around 3 hours to execute on fast machines). Of course, we might improve our ability to perform parallel testing, or perhaps reducing test scope. Bottom line, the thing here is to have available hardware externally accessible, just like the buildbot that was setup, mentioned previously on this thread.