From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvY7Q-0003uP-7j for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:17:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvY7O-00045V-5y for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:17:00 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:38232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvY7O-00044U-3O for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:16:58 -0400 Received: by yih10 with SMTP id 10so4419929yih.4 for ; Mon, 22 Aug 2011 10:16:52 -0700 (PDT) Message-ID: <4E528F02.4040302@codemonkey.ws> Date: Mon, 22 Aug 2011 12:16:50 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E5289B0.9060705@redhat.com> In-Reply-To: <4E5289B0.9060705@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Merging invasive changes (Was Re: [PULL][v2] Memory API fix) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel , KVM list Hi, This is a summary from a discussion Avi and I had earlier about merging invasive changes (like the memory API) into the tree in a more fluid fashion. Here's my suggestions: - Invasive changes over a long period of time (multi batches) should be done via git pull. patch (and therefore git-am) sucks at resolving conflicts which are a given for these types of changes. git-merge is much better at this. - Pull requests should be prefixed with '[PULL]'. - Patches should go to the ML as often as they are created. Small sets of patches can depend on each other. Don't dump 40 patches and then submit a pull request the next day. - Pull requests should be batched in a 1-2 week period after having received reviews or sufficient time to be reviewed. If it's something that really needs review, make sure it gets review before doing the pull request. Good judgement is required here. Batching is important to avoid breaking the tree daily. Exceptions will happen and that's okay, but they should be exceptions. - Patches destined for a subsystem should be prefixed with a subsystem marker. For instance, '[PATCH] block: fix QED blah blah'. If I see the prefix for a known maintained subsystem, I will delete the patch from my own queue. - Subsystems are 'known maintained' by having an entry in MAINTAINERS and by having a responsive maintainer. - Invasive, but mechanical changes shouldn't be overly split. 60 four line patches that makes the same pattern of change are harder to review than 6 forty line patches that apply the same pattern repeatedly. - Non-mechanical changes should be split of course based on logical functional areas. Regards, Anthony Liguori On 08/22/2011 11:54 AM, Avi Kivity wrote: > [v2: fix git url...] > > Anthony, please pull from: > > git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core > > to receive a memory API fix. The fix is not required for any of the > already merged patches, but is needed by other patches in my queue. > > I am sending core patches separately than the conversions to increase > their visibility. > > > (and I'll take this opportunity to announce a new layout for the branch: > > - memory/core - core fixes, usually not rebased > - memory/batch - pending batch > - memory/queue - the rest of the patches in my queue > - memory/master - a merge of the first three; please post patches based > on this branch > > this will allow me to fast-path core fixes without rebasing > memory/batch, except when a dependency is involved.) > > Richard Henderson (1): > memory: Fix old_portio vs non-zero offset > > memory.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) >