From: Anthony Liguori <anthony@codemonkey.ws>
To: "Eduardo Habkost" <ehabkost@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org,
KVM devel mailing list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>
Subject: Re: KVM call agenda for Tuesda, August 28th
Date: Tue, 28 Aug 2012 14:15:30 -0500 [thread overview]
Message-ID: <87a9xebzfx.fsf@codemonkey.ws> (raw)
In-Reply-To: <20120828180349.GT2886@otherpad.lan.raisama.net>
Eduardo Habkost <ehabkost@redhat.com> 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@redhat.com> 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.
Regards,
Anthony Liguori
>
> --
> Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Eduardo Habkost" <ehabkost@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org,
KVM devel mailing list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesda, August 28th
Date: Tue, 28 Aug 2012 14:15:30 -0500 [thread overview]
Message-ID: <87a9xebzfx.fsf@codemonkey.ws> (raw)
In-Reply-To: <20120828180349.GT2886@otherpad.lan.raisama.net>
Eduardo Habkost <ehabkost@redhat.com> 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@redhat.com> 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.
Regards,
Anthony Liguori
>
> --
> Eduardo
next prev parent reply other threads:[~2012-08-28 19:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-27 22:54 KVM call agenda for Tuesda, August 28th Juan Quintela
2012-08-27 22:54 ` [Qemu-devel] " Juan Quintela
2012-08-28 13:30 ` Eduardo Habkost
2012-08-28 13:30 ` [Qemu-devel] " Eduardo Habkost
2012-08-28 13:43 ` Juan Quintela
2012-08-28 13:43 ` [Qemu-devel] " Juan Quintela
2012-08-28 13:48 ` Eduardo Habkost
2012-08-28 13:55 ` Peter Maydell
2012-08-28 13:55 ` [Qemu-devel] " Peter Maydell
2012-08-28 14:27 ` Eduardo Habkost
2012-08-28 14:27 ` Eduardo Habkost
2012-08-28 17:59 ` Andreas Färber
2012-08-28 17:59 ` Andreas Färber
2012-08-28 18:03 ` Eduardo Habkost
2012-08-28 18:03 ` [Qemu-devel] " Eduardo Habkost
2012-08-28 19:15 ` Anthony Liguori [this message]
2012-08-28 19:15 ` Anthony Liguori
2012-08-28 19:28 ` Eduardo Habkost
2012-08-28 19:28 ` [Qemu-devel] " Eduardo Habkost
2012-08-28 19:59 ` Anthony Liguori
2012-08-28 19:59 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a9xebzfx.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.