From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVNgq-0005td-83 for qemu-devel@nongnu.org; Tue, 29 Nov 2011 08:25:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RVNgm-0007QY-31 for qemu-devel@nongnu.org; Tue, 29 Nov 2011 08:25:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVNgl-0007QM-S8 for qemu-devel@nongnu.org; Tue, 29 Nov 2011 08:25:36 -0500 From: Juan Quintela In-Reply-To: <4ED3AA22.1040005@redhat.com> (Avi Kivity's message of "Mon, 28 Nov 2011 17:34:58 +0200") References: <87vcq4nx3d.fsf@trasno.mitica> <4ED39A82.5060501@codemonkey.ws> <4ED39B06.10002@redhat.com> <4ED39C33.1020904@codemonkey.ws> <4ED3AA22.1040005@redhat.com> Date: Tue, 29 Nov 2011 14:25:32 +0100 Message-ID: <87ehwrnjqr.fsf@trasno.mitica> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] KVM call agenda for November 29 Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Developers qemu-devel , KVM devel mailing list Avi Kivity wrote: > On 11/28/2011 04:35 PM, Anthony Liguori wrote: >>> (somewhat related) memory API conversion queue merge plan >> >> >> No need to wait until tomorrow to discuss it, I guess. >> >> 1.1 will open up on Friday. I was going to make the suggestion that >> if anyone has more than 50 non-trivial patches queued in their trees >> (I suspect a few people do), they split up the pull requests into ~50 >> or so chunks and send them with a week or so spacing. >> >> 50 is just a random number. Just split the requests into reasonable >> chunks so master doesn't totally fall apart all at once :-) >> >> I think memory API may be a special case since a lot of the changes >> are trivial. So I would expect a larger pull request for the memory >> API bits. > > Yes, for the memory API conversion I'd like use 126 patch chunks. While > there are probably a few regressions lurking in there, it's easily > bisectable and fixable. Better in than out. Bad boy, you should use 128 patchs chunks O:-) I have the vmstate cpus conversion done, and for Friday would have something about virtio conversion. Later, Juan.