From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MtNQf-00069j-TG
	for qemu-devel@nongnu.org; Thu, 01 Oct 2009 11:18:50 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MtNQb-00069K-Gy
	for qemu-devel@nongnu.org; Thu, 01 Oct 2009 11:18:49 -0400
Received: from [199.232.76.173] (port=57641 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MtNQb-00069H-C7
	for qemu-devel@nongnu.org; Thu, 01 Oct 2009 11:18:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:63746)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MtNQa-0006He-SN
	for qemu-devel@nongnu.org; Thu, 01 Oct 2009 11:18:45 -0400
Message-ID: <4AC4C84E.6060806@redhat.com>
Date: Thu, 01 Oct 2009 17:18:38 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/6] char: Emit 'OPENED' events on char device
	open
References: <1254225888-17093-1-git-send-email-amit.shah@redhat.com>	<1254225888-17093-2-git-send-email-amit.shah@redhat.com>	<4AC3C9FD.3050705@codemonkey.ws>	<20091001045622.GB18563@amit-x200.redhat.com>
	<4AC4A676.4050702@codemonkey.ws> <4AC4B1F1.7070103@redhat.com>
	<4AC4B336.6090301@codemonkey.ws>
In-Reply-To: <4AC4B336.6090301@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 <anthony@codemonkey.ws>
Cc: Amit Shah <amit.shah@redhat.com>, qemu-devel@nongnu.org

On 10/01/09 15:48, Anthony Liguori wrote:

> I'll remove them from staging once I see that the patches are contended.
> The reason I do this is to make sure that patches don't get dropped.

Stick everything into the staging queue, solve conflicts, just to throw 
them out again later (which might produce conflicts again) doesn't look 
like a good workflow to me.  You spend time solving patch conflicts for 
nothing.

There must be better ways to keep track of the patches ...

> There's no excuse for a patch to be on the mailing list that isn't
> properly tested (especially build tested) without an appropriate tag
> indicating that like [RFC].

Indeed.

cheers,
   Gerd