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. -- 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
