[Qemu-devel] Delaying -rc0?

[Qemu-devel] Delaying -rc0?

[Paolo Bonzini]

Looks like there are still a few pull requests pending, and Peter is on
vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
planning page in the end never got out the "draft" state.

A possible alternative schedule could be:

2015-03-10 	Tag v2.3.0-rc0
2015-03-17 	Tag v2.3.0-rc1
2015-03-24 	Tag v2.3.0-rc2
2015-03-31 	Tag v2.3.0-rc3
2015-04-03 	Tag v2.3.0      (or -rc4, with release on April 7th)

In this case maintainers should still try not to post new non-bugfix
pull requests for the coming week, while the pending ones are sorted out.

Paolo

Re: [Qemu-devel] Delaying -rc0?

[Peter Maydell]

On 2 March 2015 at 21:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Looks like there are still a few pull requests pending, and Peter is on
> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
> planning page in the end never got out the "draft" state.

Well, I said you probably didn't want to schedule rc0 for
while I was on holiday, but nobody changed the dates...

My current intention is just to keep applying pullreqs
and then to look again at where we are once I'm back at
work. There are almost certainly pending ARM patches
which I need to assemble into a pullreq too.

> A possible alternative schedule could be:
>
> 2015-03-10      Tag v2.3.0-rc0

Hugely optimistic. I'm not likely to tag rc0 my first day
back at work :-)

> 2015-03-17      Tag v2.3.0-rc1
> 2015-03-24      Tag v2.3.0-rc2
> 2015-03-31      Tag v2.3.0-rc3
> 2015-04-03      Tag v2.3.0      (or -rc4, with release on April 7th)

-- PMM

Re: [Qemu-devel] Delaying -rc0?

[Paolo Bonzini]

On 02/03/2015 13:44, Peter Maydell wrote:
> On 2 March 2015 at 21:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Looks like there are still a few pull requests pending, and Peter is on
>> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
>> planning page in the end never got out the "draft" state.
> 
> Well, I said you probably didn't want to schedule rc0 for
> while I was on holiday, but nobody changed the dates...
> 
> My current intention is just to keep applying pullreqs
> and then to look again at where we are once I'm back at
> work. There are almost certainly pending ARM patches
> which I need to assemble into a pullreq too.
> 
>> A possible alternative schedule could be:
>>
>> 2015-03-10      Tag v2.3.0-rc0
> 
> Hugely optimistic. I'm not likely to tag rc0 my first day
> back at work :-)

I'll take that as a yes for the delay and a no for the schedule...

Paolo

>> 2015-03-17      Tag v2.3.0-rc1
>> 2015-03-24      Tag v2.3.0-rc2
>> 2015-03-31      Tag v2.3.0-rc3
>> 2015-04-03      Tag v2.3.0      (or -rc4, with release on April 7th)
> 
> -- PMM
> 

Re: [Qemu-devel] Delaying -rc0?

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Mon, Mar 02, 2015 at 01:33:23PM +0100, Paolo Bonzini wrote:
> Looks like there are still a few pull requests pending, and Peter is on
> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
> planning page in the end never got out the "draft" state.
> 
> A possible alternative schedule could be:
> 
> 2015-03-10 	Tag v2.3.0-rc0
> 2015-03-17 	Tag v2.3.0-rc1
> 2015-03-24 	Tag v2.3.0-rc2
> 2015-03-31 	Tag v2.3.0-rc3
> 2015-04-03 	Tag v2.3.0      (or -rc4, with release on April 7th)
> 
> In this case maintainers should still try not to post new non-bugfix
> pull requests for the coming week, while the pending ones are sorted out.

Delaying makes sense to me.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Delaying -rc0?

[Marcel Apfelbaum]

On 03/02/2015 03:11 PM, Paolo Bonzini wrote:
>
>
> On 02/03/2015 13:44, Peter Maydell wrote:
>> On 2 March 2015 at 21:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Looks like there are still a few pull requests pending, and Peter is on
>>> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
>>> planning page in the end never got out the "draft" state.
>>
>> Well, I said you probably didn't want to schedule rc0 for
>> while I was on holiday, but nobody changed the dates...
>>
>> My current intention is just to keep applying pullreqs
>> and then to look again at where we are once I'm back at
>> work. There are almost certainly pending ARM patches
>> which I need to assemble into a pullreq too.
>>
>>> A possible alternative schedule could be:
>>>
>>> 2015-03-10      Tag v2.3.0-rc0
>>
>> Hugely optimistic. I'm not likely to tag rc0 my first day
>> back at work :-)
Good!

I want the "multi pci root buses" feature to get in 2.3 and is depending
on Igor's dynamic ACPI series that is still waiting in the PULL request.
Any news with that?

Thanks,
Marcel

>
> I'll take that as a yes for the delay and a no for the schedule...
>
> Paolo
>
>>> 2015-03-17      Tag v2.3.0-rc1
>>> 2015-03-24      Tag v2.3.0-rc2
>>> 2015-03-31      Tag v2.3.0-rc3
>>> 2015-04-03      Tag v2.3.0      (or -rc4, with release on April 7th)
>>
>> -- PMM
>>
>

Re: [Qemu-devel] Delaying -rc0?

[Michael S. Tsirkin]

On Mon, Mar 02, 2015 at 01:33:23PM +0100, Paolo Bonzini wrote:
> Looks like there are still a few pull requests pending, and Peter is on
> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
> planning page in the end never got out the "draft" state.

I think at this point we basically don't have a schedule for 2.3. Let's
just wait until Peter is back, and then set dates for soft, hard freeze
and rc0.

-- 
MST

Re: [Qemu-devel] Delaying -rc0?

[Paolo Bonzini]

On 03/03/2015 14:12, Marcel Apfelbaum wrote:
> On 03/02/2015 03:11 PM, Paolo Bonzini wrote:
>>
>>
>> On 02/03/2015 13:44, Peter Maydell wrote:
>>> On 2 March 2015 at 21:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> Looks like there are still a few pull requests pending, and Peter is on
>>>> vacation.  Should we really enter hard feature freeze tomorrow?  The
>>>> 2.3
>>>> planning page in the end never got out the "draft" state.
>>>
>>> Well, I said you probably didn't want to schedule rc0 for
>>> while I was on holiday, but nobody changed the dates...
>>>
>>> My current intention is just to keep applying pullreqs
>>> and then to look again at where we are once I'm back at
>>> work. There are almost certainly pending ARM patches
>>> which I need to assemble into a pullreq too.
>>>
>>>> A possible alternative schedule could be:
>>>>
>>>> 2015-03-10      Tag v2.3.0-rc0
>>>
>>> Hugely optimistic. I'm not likely to tag rc0 my first day
>>> back at work :-)
> Good!
> 
> I want the "multi pci root buses" feature to get in 2.3 and is depending
> on Igor's dynamic ACPI series that is still waiting in the PULL request.

QEMU 2.3's SeaBIOS is already frozen to 1.8.0.  Does it have the
required support?

Paolo

Re: [Qemu-devel] Delaying -rc0?

[Gerd Hoffmann]

  Hi,

> >>>> A possible alternative schedule could be:
> >>>>
> >>>> 2015-03-10      Tag v2.3.0-rc0
> >>>
> >>> Hugely optimistic. I'm not likely to tag rc0 my first day
> >>> back at work :-)
> > Good!
> > 
> > I want the "multi pci root buses" feature to get in 2.3 and is depending
> > on Igor's dynamic ACPI series that is still waiting in the PULL request.
> 
> QEMU 2.3's SeaBIOS is already frozen to 1.8.0.  Does it have the
> required support?

seabios patches are not committed yet, which I don't see as blocker
though.  The patches are not that complex, we can cherry-pick them from
master into the (to be created) stable-1.8.0 branch & roll out a release
for qemu 2.3

I also think something like 2015-03-17 (maybe even later) would be
better for -rc0, given that we have quite a few patches on the list with
dependencies to not-yet merged pulls, due to peter's vacation backlog.
It'll need some time to merge pulls, rebase patches, retest, repost ...

cheers,
  Gerd

Re: [Qemu-devel] Delaying -rc0?

[Marcel Apfelbaum]

On 03/03/2015 03:57 PM, Paolo Bonzini wrote:
>
>
> On 03/03/2015 14:12, Marcel Apfelbaum wrote:
>> On 03/02/2015 03:11 PM, Paolo Bonzini wrote:
>>>
>>>
>>> On 02/03/2015 13:44, Peter Maydell wrote:
>>>> On 2 March 2015 at 21:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>> Looks like there are still a few pull requests pending, and Peter is on
>>>>> vacation.  Should we really enter hard feature freeze tomorrow?  The
>>>>> 2.3
>>>>> planning page in the end never got out the "draft" state.
>>>>
>>>> Well, I said you probably didn't want to schedule rc0 for
>>>> while I was on holiday, but nobody changed the dates...
>>>>
>>>> My current intention is just to keep applying pullreqs
>>>> and then to look again at where we are once I'm back at
>>>> work. There are almost certainly pending ARM patches
>>>> which I need to assemble into a pullreq too.
>>>>
>>>>> A possible alternative schedule could be:
>>>>>
>>>>> 2015-03-10      Tag v2.3.0-rc0
>>>>
>>>> Hugely optimistic. I'm not likely to tag rc0 my first day
>>>> back at work :-)
>> Good!
>>
>> I want the "multi pci root buses" feature to get in 2.3 and is depending
>> on Igor's dynamic ACPI series that is still waiting in the PULL request.
>
> QEMU 2.3's SeaBIOS is already frozen to 1.8.0.  Does it have the
> required support?
Hi Paolo,
(CCed Kevin and Gerd)

Well, the support was ready in time, see:
    [SeaBIOS] [PATCH V3 0/2] fw/pci: better support for multiple host bridges
    http://permalink.gmane.org/gmane.comp.bios.coreboot.seabios/8681
but the SeaBIOS maintainers preferred to see first the QEMU submission
getting accepted.

In the mean time this series depends on Igor's ACPI dynamic series that took
a lot of time to review and even Michael's PULL request with it is not yet in master.
The latest version is fully functional, the only reason is marked as 'RFC" is because
of the ACPI series API kept changing.

I will submit in a day or two the another version rebased on Michael's for_upstream tag.
(I was waiting for it to get in master...)
I really want to see this series into 2.3, please advise.
Thanks,
Marcel




>
> Paolo
>

Re: [Qemu-devel] Delaying -rc0?

[Peter Maydell]

On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
> In the mean time this series depends on Igor's ACPI dynamic series that took
> a lot of time to review and even Michael's PULL request with it is not yet
> in master.

You can view this as an argument against enormous pull requests
with nearly a hundred patches in them -- they're much more likely
to hit multiple issues in submission with minor things that need
fixing, simply because of their size...

thanks
-- PMM

Re: [Qemu-devel] Delaying -rc0?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
>> In the mean time this series depends on Igor's ACPI dynamic series that took
>> a lot of time to review and even Michael's PULL request with it is not yet
>> in master.
>
> You can view this as an argument against enormous pull requests
> with nearly a hundred patches in them -- they're much more likely
> to hit multiple issues in submission with minor things that need
> fixing, simply because of their size...

Yes.  The current PCI pull request is clearly too big for its own
good.

Re: [Qemu-devel] Delaying -rc0?

[Markus Armbruster]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Mon, Mar 02, 2015 at 01:33:23PM +0100, Paolo Bonzini wrote:
>> Looks like there are still a few pull requests pending, and Peter is on
>> vacation.  Should we really enter hard feature freeze tomorrow?  The 2.3
>> planning page in the end never got out the "draft" state.
>
> I think at this point we basically don't have a schedule for 2.3. Let's
> just wait until Peter is back, and then set dates for soft, hard freeze
> and rc0.

Makes sense to me.

Re: [Qemu-devel] Delaying -rc0?

[Gerd Hoffmann]

  Hi,

> Well, the support was ready in time, see:
>     [SeaBIOS] [PATCH V3 0/2] fw/pci: better support for multiple host bridges
>     http://permalink.gmane.org/gmane.comp.bios.coreboot.seabios/8681
> but the SeaBIOS maintainers preferred to see first the QEMU submission
> getting accepted.

Yep, that is the usual protocol to avoid ending up with stale code in
seabios because the qemu patches never make it upstream.

I havn't seen major objections on the RfC series, so I think it is ok to
go ahead committing the seabios patches when the dependencies are
merged, we have a non-rfc patch submission, and there is agreement this
is going to be merged for 2.3.  That way we can parallelize the qemu and
seabios side of things a bit, to get both ready in time for -rc0.

> In the mean time this series depends on Igor's ACPI dynamic series that took
> a lot of time to review and even Michael's PULL request with it is not yet in master.

That's the real blocking thing here ...

cheers,
  Gerd

Re: [Qemu-devel] Delaying -rc0?

[Gerd Hoffmann]

On Mi, 2015-03-04 at 08:27 +0100, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
> >> In the mean time this series depends on Igor's ACPI dynamic series that took
> >> a lot of time to review and even Michael's PULL request with it is not yet
> >> in master.
> >
> > You can view this as an argument against enormous pull requests
> > with nearly a hundred patches in them -- they're much more likely
> > to hit multiple issues in submission with minor things that need
> > fixing, simply because of their size...
> 
> Yes.  The current PCI pull request is clearly too big for its own
> good.

... and it has non-pci stuff in there too.  Guess it would make sense to
split stuff into multiple queues (acpi, pc, acpi, virtio, ...).  Helps
to keep the size reasonable.  I think it works better overall, even if
it is annoying at times when there are patch dependencies between
branches.

cheers,
  Gerd

Re: [Qemu-devel] Delaying -rc0?

[Michael S. Tsirkin]

On Wed, Mar 04, 2015 at 01:13:14PM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-04 at 08:27 +0100, Markus Armbruster wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > 
> > > On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
> > >> In the mean time this series depends on Igor's ACPI dynamic series that took
> > >> a lot of time to review and even Michael's PULL request with it is not yet
> > >> in master.
> > >
> > > You can view this as an argument against enormous pull requests
> > > with nearly a hundred patches in them -- they're much more likely
> > > to hit multiple issues in submission with minor things that need
> > > fixing, simply because of their size...
> > 
> > Yes.  The current PCI pull request is clearly too big for its own
> > good.
> 
> ... and it has non-pci stuff in there too.  Guess it would make sense to
> split stuff into multiple queues (acpi, pc, acpi, virtio, ...).  Helps
> to keep the size reasonable.  I think it works better overall, even if
> it is annoying at times when there are patch dependencies between
> branches.
> 
> cheers,
>   Gerd
> 

I'll look into splitting virtio out, thanks for the suggestion.

-- 
MST

Re: [Qemu-devel] Delaying -rc0?

[Michael S. Tsirkin]

On Wed, Mar 04, 2015 at 12:14:21AM +0900, Peter Maydell wrote:
> On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
> > In the mean time this series depends on Igor's ACPI dynamic series that took
> > a lot of time to review and even Michael's PULL request with it is not yet
> > in master.
> 
> You can view this as an argument against enormous pull requests
> with nearly a hundred patches in them -- they're much more likely
> to hit multiple issues in submission with minor things that need
> fixing, simply because of their size...
> 
> thanks
> -- PMM

Right. There were acpi changes by Igor and PCI changes by Markus,
trying to merge them at once is what created this.
I guess I could instead just do two unrelated pull requests
that can be merged in parallel. Though in Marcel's case, the
problems were all in Igor's patches and these are exactly
the ones Marcel's code depends on.

-- 
MST

Re: [Qemu-devel] Delaying -rc0?

[Markus Armbruster]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, Mar 04, 2015 at 12:14:21AM +0900, Peter Maydell wrote:
>> On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
>> > In the mean time this series depends on Igor's ACPI dynamic series that took
>> > a lot of time to review and even Michael's PULL request with it is not yet
>> > in master.
>> 
>> You can view this as an argument against enormous pull requests
>> with nearly a hundred patches in them -- they're much more likely
>> to hit multiple issues in submission with minor things that need
>> fixing, simply because of their size...
>> 
>> thanks
>> -- PMM
>
> Right. There were acpi changes by Igor and PCI changes by Markus,

The latter is my "[PATCH 00/10] pci: Partial conversion to realize".
Quite a few pending series depend on it.

> trying to merge them at once is what created this.
> I guess I could instead just do two unrelated pull requests
> that can be merged in parallel. Though in Marcel's case, the
> problems were all in Igor's patches and these are exactly
> the ones Marcel's code depends on.

If we can decouple the two, problems with one won't hold up the other
anymore.

I can do a pull request for just my series, if that helps.  But I'm
prepared to leave that coveted, glamorous and rewarding job to you ;)

Re: [Qemu-devel] Delaying -rc0?

[Michael S. Tsirkin]

On Wed, Mar 04, 2015 at 05:48:37PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Wed, Mar 04, 2015 at 12:14:21AM +0900, Peter Maydell wrote:
> >> On 4 March 2015 at 00:07, Marcel Apfelbaum <marcel@redhat.com> wrote:
> >> > In the mean time this series depends on Igor's ACPI dynamic series that took
> >> > a lot of time to review and even Michael's PULL request with it is not yet
> >> > in master.
> >> 
> >> You can view this as an argument against enormous pull requests
> >> with nearly a hundred patches in them -- they're much more likely
> >> to hit multiple issues in submission with minor things that need
> >> fixing, simply because of their size...
> >> 
> >> thanks
> >> -- PMM
> >
> > Right. There were acpi changes by Igor and PCI changes by Markus,
> 
> The latter is my "[PATCH 00/10] pci: Partial conversion to realize".
> Quite a few pending series depend on it.
> 
> > trying to merge them at once is what created this.
> > I guess I could instead just do two unrelated pull requests
> > that can be merged in parallel. Though in Marcel's case, the
> > problems were all in Igor's patches and these are exactly
> > the ones Marcel's code depends on.
> 
> If we can decouple the two, problems with one won't hold up the other
> anymore.
> 
> I can do a pull request for just my series, if that helps.

I think it's not necessary at this point.

>  But I'm
> prepared to leave that coveted, glamorous and rewarding job to you ;)