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

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

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.

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

[Eduardo Habkost]

On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
> 
> Hi
> 
> Please send in any agenda items you are interested in covering.

- *-user and qdev (recent RFCs didn't get many comments in the list, and
  I don't see a conclusion);
- 1.2 branching, or creation of a "cpu-next" tree where "good to be
  merged" patches can live until 1.2 is done;
- CPU code roadmap[1].

[1] For reference, this is the list of pending work that I want to
target for 1.3:

- -cpu help fix
- CPU DeviceState
- move CPU models to C
- kill cpudef
- unduplicate feature names
- CPU properties
- CPU model classes
- Fix -cpu host to use GET_SUPPORTED_CPUID properly
- Fix -cpu check/enforce brokenness
  (including lots of refactoring of the currently-broken feature-flag
  checking code)
- APIC ID threads/cores topology fix

-- 
Eduardo

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

[Juan Quintela]

Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
>> 
>> Hi
>> 
>> Please send in any agenda items you are interested in covering.
>
> - *-user and qdev (recent RFCs didn't get many comments in the list, and
>   I don't see a conclusion);
> - 1.2 branching, or creation of a "cpu-next" tree where "good to be
>   merged" patches can live until 1.2 is done;
> - CPU code roadmap[1].
>
> [1] For reference, this is the list of pending work that I want to
> target for 1.3:
>
> - -cpu help fix
> - CPU DeviceState
> - move CPU models to C
> - kill cpudef
> - unduplicate feature names
> - CPU properties
> - CPU model classes
> - Fix -cpu host to use GET_SUPPORTED_CPUID properly
> - Fix -cpu check/enforce brokenness
>   (including lots of refactoring of the currently-broken feature-flag
>   checking code)
> - APIC ID threads/cores topology fix

And I was about to cancel de call.  Only problem is that I have been
told that lot of people is on San Diego, but we can try to see if there
is enough quorum (I didn't realize the San Diego "problem").

Later, Juan.

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

[Eduardo Habkost]

On Tue, Aug 28, 2012 at 03:43:17PM +0200, Juan Quintela wrote:
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
> >> 
> >> Hi
> >> 
> >> Please send in any agenda items you are interested in covering.
> >
> > - *-user and qdev (recent RFCs didn't get many comments in the list, and
> >   I don't see a conclusion);
> > - 1.2 branching, or creation of a "cpu-next" tree where "good to be
> >   merged" patches can live until 1.2 is done;
> > - CPU code roadmap[1].
> >
> > [1] For reference, this is the list of pending work that I want to
> > target for 1.3:
> >
> > - -cpu help fix
> > - CPU DeviceState
> > - move CPU models to C
> > - kill cpudef
> > - unduplicate feature names
> > - CPU properties
> > - CPU model classes
> > - Fix -cpu host to use GET_SUPPORTED_CPUID properly
> > - Fix -cpu check/enforce brokenness
> >   (including lots of refactoring of the currently-broken feature-flag
> >   checking code)
> > - APIC ID threads/cores topology fix
> 
> And I was about to cancel de call.  Only problem is that I have been
> told that lot of people is on San Diego, but we can try to see if there
> is enough quorum (I didn't realize the San Diego "problem").

No problem. We can try to get that discussed on the list, or wait until
next week.

-- 
Eduardo

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

[Peter Maydell]

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

-- PMM

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

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

But in the end, this is more a problem of patch review capacity, than
about having a branch created. One can easily create a branch somewhere
(I am going to create a "cpu-next" branch for the patches that seem to
be "ready to go"), and propose to get it merged after 1.2 is out. But
the problem is to have enough eyeballs to look at it to decide if each
patch should go into that branch, or not.

-- 
Eduardo

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

[Andreas Färber]

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.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Eduardo Habkost]

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?

-- 
Eduardo

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

[Anthony Liguori]

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

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

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

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

[Anthony Liguori]

Eduardo Habkost <ehabkost@redhat.com> writes:

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