From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MPGFP-0007CP-So
	for qemu-devel@nongnu.org; Fri, 10 Jul 2009 09:34:43 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MPGFK-00075M-Hj
	for qemu-devel@nongnu.org; Fri, 10 Jul 2009 09:34:42 -0400
Received: from [199.232.76.173] (port=48057 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MPGFK-000756-CE
	for qemu-devel@nongnu.org; Fri, 10 Jul 2009 09:34:38 -0400
Received: from verein.lst.de ([213.95.11.210]:33151)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MPGFJ-0003oE-S9
	for qemu-devel@nongnu.org; Fri, 10 Jul 2009 09:34:38 -0400
Date: Fri, 10 Jul 2009 15:34:31 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] qemu-iotests: make a few more tests generic
Message-ID: <20090710133431.GA17096@lst.de>
References: <20090708194143.GA14640@lst.de> <4A55BF62.9070702@redhat.com>
	<20090709132513.GA13722@lst.de> <4A56F22A.8030406@redhat.com>
	<4A573908.5020600@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A573908.5020600@us.ibm.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Fri, Jul 10, 2009 at 07:50:16AM -0500, Anthony Liguori wrote:
> Christoph posted an alternative patch and there didn't seem to be a 
> consensus on the thread about what solution was the best one.  See 
> http://article.gmane.org/gmane.comp.emulators.qemu/46032/match=block+clean+up+after.  

either one is much much better than nothing.

> It's also up to the submitter to keep track of their patches.  If they 
> think one should be applied that hasn't been, they need to follow up on it. 
> The only way to scale here is to push as much work as possible to the 
> outer-most nodes.

It's just really hard to track stuff without feedback.  You only flush
your queue very sproadicly, so some kind of indicator that it is in the
queue would be extremly helpful.  Just an ok, I'll queue it to mean that
it's not lost means we know it's been deal with in some way, and we can
ping patches that haven't gotten any feedback for say a week.