Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote: >> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: >> >> > On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber 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 <ehabkost@xxxxxxxxxx> 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... >> >> > >> >> > 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. >> >> >> >> 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. > > 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 > > -- > Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
