Re: [Qemu-devel] KVM call agenda for Tuesda, August 28th

[Eduardo Habkost]

On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <address@hidden> 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 <address@hidden> 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