From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6RwN-0006yo-3F for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:59:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6RwL-0000di-Q6 for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:59:11 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:46136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6RwL-0000db-L7 for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:59:09 -0400 Received: by obbta14 with SMTP id ta14so10584941obb.4 for ; Tue, 28 Aug 2012 12:59:08 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20120828192800.GV2886@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> <87a9xebzfx.fsf@codemonkey.ws> <20120828192800.GV2886@otherpad.lan.raisama.net> Date: Tue, 28 Aug 2012 14:59:03 -0500 Message-ID: <87txvm94ag.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 Cc: Peter Maydell , KVM devel mailing list , Juan Quintela , qemu-devel@nongnu.org, Igor Mammedov , Andreas =?utf-8?Q?F=C3=A4rber?= Eduardo Habkost writes: > On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote: >> Eduardo Habkost writes: >>=20 >> > 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 wro= te: >> >> >>> - 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? >>=20 >> I'd prefer not to do next trees unless it's for a clear subsystem that >> already exists and will continue to exist. >>=20 >> 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. > > How exactly this would cause pain? I am already maintaining a branch for > myself with a huge list of patches, to be able to continue working on > things I want to send to 1.3. > > The difference is that in addition to that, I am willing to gather the > patches that seem to be "ready to go" on a more stable branch, and send > them as a single pull request (or even a plain patch series by mail) to > the list once 1.2 is out. Patches sent during the release window usually don't have enough so just pulling them sort of defeats the purpose. Regards, Anthony Liguori > > --=20 > Eduardo