From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3ASA-0005Yn-7Z for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:28:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3AS3-0005OR-HC for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:28:48 -0400 Received: from [199.232.76.173] (port=56775 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3AS3-0005Nu-5Y for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:28:43 -0400 Received: from ey-out-1920.google.com ([74.125.78.147]:52668) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3AS2-0003xK-G3 for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:28:42 -0400 Received: by ey-out-1920.google.com with SMTP id 3so766489eyh.14 for ; Wed, 28 Oct 2009 08:28:41 -0700 (PDT) Message-ID: <4AE86325.5090000@codemonkey.ws> Date: Wed, 28 Oct 2009 10:28:37 -0500 From: Anthony Liguori 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> <4AE85BC6.1080508@redhat.com> In-Reply-To: <4AE85BC6.1080508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Mark McLoughlin , Anthony Liguori , qemu-devel@nongnu.org Gerd Hoffmann wrote: > 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. That would require a series to be merged within a very short time period which does not allow appropriate review on the list. > 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. There are certain patches that I could merge more quickly but I don't think it's reasonable to merge large, potentially controversial series without letting them sit on the list for a week or so to give people a chance to review. In this case, these two series definitely fall into the later category. Regards, Anthony Liguori