From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6RGC-0006MJ-AV for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:15:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6RGB-0004en-3o for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:15:36 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:36831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6RGA-0004ei-Uk for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:15:35 -0400 Received: by obbta14 with SMTP id ta14so10504572obb.4 for ; Tue, 28 Aug 2012 12:15:34 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20120828180349.GT2886@otherpad.lan.raisama.net> References: <87ipc4gd35.fsf@elfo.mitica> <20120828133028.GB6223@otherpad.lan.raisama.net> <20120828142707.GD6223@otherpad.lan.raisama.net> <503D0713.3090302@suse.de> <20120828180349.GT2886@otherpad.lan.raisama.net> Date: Tue, 28 Aug 2012 14:15:30 -0500 Message-ID: <87a9xebzfx.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for Tuesda, August 28th List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Peter Maydell , Igor Mammedov , qemu-devel@nongnu.org, KVM devel mailing list , Juan Quintela Eduardo Habkost writes: > On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas F=C3=A4rber wrote: >> Am 28.08.2012 16:27, schrieb Eduardo Habkost: >> > On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote: >> >> On 28 August 2012 14:30, Eduardo Habkost wrote: >> >>> - 1.2 branching, or creation of a "cpu-next" tree where "good to be >> >>> merged" patches can live until 1.2 is done; >> >> >> >> With 1.3 due for release in just over a week, it seems unlikely >> >> that it's worth branching at this point... >> >=20 >> > Well, the closer to the release, the smaller the cost of branching as = we >> > won't have many patches entering the 1.2 branch, anyway. >>=20 >> The idea behind the new release model is to never branch for releases, >> so that we can easily bisect between v1.2 and v1.3, both tags being on >> the same branch. So I don't think a 1.2 branch is likely. > > That means that every branch to be merged after 1.2 has to be rebased on > top of 1.2 before being merged? I'd prefer not to do next trees unless it's for a clear subsystem that already exists and will continue to exist. If someone wants to be a CPU subsystem maintainer, that's great, and we can keep the tree open regardless of the release. But just having a temporary tree for 3 weeks is more pain than it's worth. Regards, Anthony Liguori > > --=20 > Eduardo