From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mn6L9-0001hl-GP for qemu-devel@nongnu.org; Mon, 14 Sep 2009 03:51:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mn6L5-0001gO-Rp for qemu-devel@nongnu.org; Mon, 14 Sep 2009 03:51:11 -0400 Received: from [199.232.76.173] (port=34329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mn6L5-0001gJ-Mo for qemu-devel@nongnu.org; Mon, 14 Sep 2009 03:51:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:31075) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mn6L5-0002C0-72 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 03:51:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mn6L3-0002mO-I3 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 03:51:05 -0400 Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? From: Mark McLoughlin In-Reply-To: <4AAD1B83.5010602@redhat.com> References: <20090902074905.GB25711@chrom.inf.tu-dresden.de> <20090909121817.GA21997@chrom.inf.tu-dresden.de> <4AA7A6EC.10907@codemonkey.ws> <20090910070336.GD3351@amit-x200.redhat.com> <4AA90592.7080100@codemonkey.ws> <4AA90F7F.2030709@redhat.com> <4AA92122.3050103@codemonkey.ws> <4AA924AE.8060807@redhat.com> <4AA927D8.7000900@codemonkey.ws> <4AA92ADF.80003@redhat.com> <1252607396.3403.57.camel@blaa> <4AA9481D.1090508@redhat.com> <1252615019.3403.75.camel@blaa> <4AAD1B83.5010602@redhat.com> Content-Type: text/plain Date: Mon, 14 Sep 2009 08:49:55 +0100 Message-Id: <1252914595.3491.27.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Amit Shah , Bernhard Kauer , qemu-devel@nongnu.org On Sun, 2009-09-13 at 19:19 +0300, Avi Kivity wrote: > On 09/10/2009 11:36 PM, Mark McLoughlin wrote: > > On Thu, 2009-09-10 at 21:40 +0300, Avi Kivity wrote: > > > > > >> (and we're quite far from catching every regression btw). > >> > > That's kind of my point. A lot of regressions are only found after > > they've been pushed. Delaying a push delays finding those regressions. > > > > That makes sense if the regression tests don't find any regressions. Or if the regression tests take too long - rather than regression tests that take 5 hours to run, I'd prefer to see a subset of those which takes e.g. 30 minutes be used to sanity check a tree before pushing it. This would allow smaller batches to be pushed more regularly, while the more in-depth testing can be done less regularly on batches not much larger than are being pushed now. > If > they do, then pushing despite those regressions means everyone is now > hitting the regressions, swearing, and trying to work around them. We > get massive parallelism but little progress. Not all regressions are equal. I wouldn't mind some regressions in the tree so long as they are being tracked as "must be fixed" before the release. Clearly anything causing people to swear should be reverted. Assuming you can tell which patch caused the problem. > > Don't get me wrong - we certainly want to avoid regressions and doing > > some testing before pushing is a good idea, but there is a balance to be > > struck. > > > > It's also the case that not all patches are equal. It should be possible > > to short-cut the process for small patches, or regression fixes, or > > patches from a trusted author who has done significant testing already. > > > > I think reducing the batch size will also help. If the batch contains > 100 patches there's a high likelihood of a regression in there. If > you're testing 10-15 patches at a time it may actually work, and if not, > you can easily guess who the offender is. The batch size is determined by the length of time the testing takes, right? But agree, with a large batch, you're more likely to find at least one regression, to struggle to figure out which patch caused the regression and to go through several iterations before you have something to push. Cheers, Mark.