From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N39xp-0000EM-P6
	for qemu-devel@nongnu.org; Wed, 28 Oct 2009 10:57:29 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N39xk-00007u-Eg
	for qemu-devel@nongnu.org; Wed, 28 Oct 2009 10:57:28 -0400
Received: from [199.232.76.173] (port=52552 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N39xk-00007j-BU
	for qemu-devel@nongnu.org; Wed, 28 Oct 2009 10:57:24 -0400
Received: from mx1.redhat.com ([209.132.183.28]:42110)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1N39xj-0005yX-Pv
	for qemu-devel@nongnu.org; Wed, 28 Oct 2009 10:57:24 -0400
Message-ID: <4AE85BC6.1080508@redhat.com>
Date: Wed, 28 Oct 2009 15:57:10 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2]
	Add virtio-net/tap support for partial csums and GSO]
References: <1256229830-28066-1-git-send-email-markmc@redhat.com>
	<1256740226.5105.59.camel@blaa>
In-Reply-To: <1256740226.5105.59.camel@blaa>
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: Mark McLoughlin <markmc@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

   Hi,

> Should either Gerd or I have merged the others' changes into our tree
> and asked you to pull? Should you just refuse conflicts and ask us to
> re-post? Or ...?

I think the best way to deal with that would be to simply not merge 
stuff which doesn't apply.  Likewise for stuff which doesn't build.

Pick one patch series, merge it, ask for a rebase of the other series, 
i.e. basically offload the conflict resolving to the patch submitter. 
Reduces your workload and non-trivial conflicts are better handled by 
the submitter anyway.

Problem is that this model doesn't work very well the bulk merges we 
have right now, so I'd suggest to also merge smaller batches more 
frequently.

cheers,
   Gerd