[Qemu-devel] QEMU 2.7 release schedule?

[Qemu-devel] QEMU 2.7 release schedule?

[Peter Maydell]

Well, time to make a decision about our release date for 2.7.

If you start out with "let's put the release in august like it
usually is but not so close to KVM Forum (24-26 Aug) as to
be likely to slip in to it", then you get something like:

Jun 21 softfreeze
Jul 12 hardfreeze, rc0
Jul 19 rc1
Jul 26 rc2
Aug 02 rc3
Aug 09 final release 2.7.0

That's with a 3-week softfreeze again, and puts softfreeze
in two weeks' time.

Anybody got any better suggestions?

thanks
-- PMM

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Christian Borntraeger]

On 06/06/2016 05:34 PM, Peter Maydell wrote:
> Well, time to make a decision about our release date for 2.7.
> 
> If you start out with "let's put the release in august like it
> usually is but not so close to KVM Forum (24-26 Aug) as to
> be likely to slip in to it", then you get something like:
> 
> Jun 21 softfreeze
> Jul 12 hardfreeze, rc0
> Jul 19 rc1
> Jul 26 rc2
> Aug 02 rc3
> Aug 09 final release 2.7.0
> 
> That's with a 3-week softfreeze again, and puts softfreeze
> in two weeks' time.
> 
> Anybody got any better suggestions?

What about making the last rc at KVM forum, get all maintainers together in a room for 2 hours
and let everybody test the last rc on their favourite platform?

If that does not work out (room/timeslot whatever) your proposal would be fine with me.
It would be a relatively short cycle, though (which I think is good). 

Christian

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Alex Bennée]

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

> Well, time to make a decision about our release date for 2.7.
>
> If you start out with "let's put the release in august like it
> usually is but not so close to KVM Forum (24-26 Aug) as to
> be likely to slip in to it", then you get something like:
>
> Jun 21 softfreeze
> Jul 12 hardfreeze, rc0
> Jul 19 rc1
> Jul 26 rc2
> Aug 02 rc3
> Aug 09 final release 2.7.0
>
> That's with a 3-week softfreeze again, and puts softfreeze
> in two weeks' time.

Wow is it that time already, it feels like the tree only just opened up
again. I guess that's the ever forward march of progress.

So from my point of view w.r.t to MTTCG I'm under no illusions about it
being ready for the 2.7 window. In fact I think our current aim is to
have the pieces in place so that we can hammer out the final details or
merging at KVM Forum. However it would be good to get pre-cursor work
merged in this window, QHT being the main thing which has had a number
of rounds of review so far. We'll also review the current MTTCG patch
sets to see what is ready and not directly tied to MTTCG to be brought
forward for merging this window (a bunch of the TCG clean-ups have
already gone in thanks to Sergey).

>
> Anybody got any better suggestions?

Do you collect a list of baking features likely to go in or is it just a
case of "patches have been on list by now"?

>
> thanks
> -- PMM


--
Alex Bennée

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Peter Maydell]

On 7 June 2016 at 08:29, Alex Bennée <alex.bennee@linaro.org> wrote:
> Do you collect a list of baking features likely to go in or is it just a
> case of "patches have been on list by now"?

I don't collect feature lists; I treat QEMU releases as roughly
fixed dates, and whatever's ready to go in gets in. We have
settled down to one in April/May, one in August/September and
one in December. I'm not strongly attached to the process we
have, but it seems to work out by and large.

thanks
-- PMM

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Michael Roth]

Quoting Alex Bennée (2016-06-07 02:29:38)
> 
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > Well, time to make a decision about our release date for 2.7.
> >
> > If you start out with "let's put the release in august like it
> > usually is but not so close to KVM Forum (24-26 Aug) as to
> > be likely to slip in to it", then you get something like:
> >
> > Jun 21 softfreeze
> > Jul 12 hardfreeze, rc0
> > Jul 19 rc1
> > Jul 26 rc2
> > Aug 02 rc3
> > Aug 09 final release 2.7.0
> >
> > That's with a 3-week softfreeze again, and puts softfreeze
> > in two weeks' time.
> 
> Wow is it that time already, it feels like the tree only just opened up
> again. I guess that's the ever forward march of progress.

I think it is actually bit shorter of a window this time. The last few
releases had around 2.5 to 3 months between n-1 release and hard freeze / rc0
for n+1, but the proposed date would be just around 2 months.

Accounting for the possibility of an extra RC, more than 1 week more of
development time would make the possibility of the release pushing into
KVM Forum fairly likely.

But maybe an additional 1 week till soft freeze might be doable? I'm guessing
that doesn't make a big difference for something like MTTCG, but it could
be useful for others who didn't anticipate softfreeze being that close.

Being in late RC during KVM Forum also sounds like it could be productive,
but I'm not sure I'd want to be in that position if I was Peter...

> 
> So from my point of view w.r.t to MTTCG I'm under no illusions about it
> being ready for the 2.7 window. In fact I think our current aim is to
> have the pieces in place so that we can hammer out the final details or
> merging at KVM Forum. However it would be good to get pre-cursor work
> merged in this window, QHT being the main thing which has had a number
> of rounds of review so far. We'll also review the current MTTCG patch
> sets to see what is ready and not directly tied to MTTCG to be brought
> forward for merging this window (a bunch of the TCG clean-ups have
> already gone in thanks to Sergey).
> 
> >
> > Anybody got any better suggestions?
> 
> Do you collect a list of baking features likely to go in or is it just a
> case of "patches have been on list by now"?
> 
> >
> > thanks
> > -- PMM
> 
> 
> --
> Alex Bennée
> 

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Peter Maydell]

On 7 June 2016 at 18:29, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> I think it is actually bit shorter of a window this time. The last few
> releases had around 2.5 to 3 months between n-1 release and hard freeze / rc0
> for n+1, but the proposed date would be just around 2 months.

Yeah, it's a bit short because the late-breaking CVEs meant we
didn't release 2.6 until about two weeks later than we planned.

If we want to have 2.5 months between n-1 and rc0, that would be
something like
 softfreeze 5 july
 hardfreeze/rc0 26 july
 rc1 2 august
 rc2 9 august
 rc3 16 august
 release 22 august (before kvm forum) if we're lucky, or
  30 august if we're not (more likely)

[these dates are all +2 weeks on the previous suggestion.]

> Being in late RC during KVM Forum also sounds like it could
> be productive, but I'm not sure I'd want to be in that position
> if I was Peter...

>From my POV the rc3-to-rc4 stage is not that much work, but
it's hard to predict who might be the person with the last-minute
required fix (which is usually why we end up with about a week
of slip over the theoretical schedule). The tree is not supposed
to change at that point. I can do the rc/release cutting mechanics
remotely (assuming no disasters like stolen laptops etc); how about
your part with the tarballs? Otherwise we can just do it either
before or after the conference depending on how it goes.

But I think the real problem with a schedule which expects a
release at the tail end of August is that we then only have
three and a half months left til mid-December which is in
practice the latest we want to do a release given holidays.
So we can only avoid the short dev period this time round by
having a short one next time instead.

Maybe we could have +1 week rather than +0 or +2 (so softfreeze
28 June, rc0 19 July, release 16 August), as you suggest. That's
currently feeling like the best compromise to me.

thanks
-- PMM

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Michael Roth]

Quoting Peter Maydell (2016-06-07 13:45:06)
> On 7 June 2016 at 18:29, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > I think it is actually bit shorter of a window this time. The last few
> > releases had around 2.5 to 3 months between n-1 release and hard freeze / rc0
> > for n+1, but the proposed date would be just around 2 months.
> 
> Yeah, it's a bit short because the late-breaking CVEs meant we
> didn't release 2.6 until about two weeks later than we planned.
> 
> If we want to have 2.5 months between n-1 and rc0, that would be
> something like
>  softfreeze 5 july
>  hardfreeze/rc0 26 july
>  rc1 2 august
>  rc2 9 august
>  rc3 16 august
>  release 22 august (before kvm forum) if we're lucky, or
>   30 august if we're not (more likely)
> 
> [these dates are all +2 weeks on the previous suggestion.]
> 
> > Being in late RC during KVM Forum also sounds like it could
> > be productive, but I'm not sure I'd want to be in that position
> > if I was Peter...
> 
> From my POV the rc3-to-rc4 stage is not that much work, but
> it's hard to predict who might be the person with the last-minute
> required fix (which is usually why we end up with about a week
> of slip over the theoretical schedule). The tree is not supposed
> to change at that point. I can do the rc/release cutting mechanics
> remotely (assuming no disasters like stolen laptops etc); how about
> your part with the tarballs? Otherwise we can just do it either
> before or after the conference depending on how it goes.

Same for me, should be able to kick off everything remotely.

> 
> But I think the real problem with a schedule which expects a
> release at the tail end of August is that we then only have
> three and a half months left til mid-December which is in
> practice the latest we want to do a release given holidays.
> So we can only avoid the short dev period this time round by
> having a short one next time instead.
> 
> Maybe we could have +1 week rather than +0 or +2 (so softfreeze
> 28 June, rc0 19 July, release 16 August), as you suggest. That's
> currently feeling like the best compromise to me.

Yah, I think I agree. We'll have to make up the 2 weeks lost at some
point, but spreading it out avoids us finding ourselves in a similar
situation next release. Seems like maybe there may be more work
being targetted for 2.8 as well.

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] QEMU 2.7 release schedule?

[Peter Maydell]

On 7 June 2016 at 20:15, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> Quoting Peter Maydell (2016-06-07 13:45:06)
>> But I think the real problem with a schedule which expects a
>> release at the tail end of August is that we then only have
>> three and a half months left til mid-December which is in
>> practice the latest we want to do a release given holidays.
>> So we can only avoid the short dev period this time round by
>> having a short one next time instead.
>>
>> Maybe we could have +1 week rather than +0 or +2 (so softfreeze
>> 28 June, rc0 19 July, release 16 August), as you suggest. That's
>> currently feeling like the best compromise to me.
>
> Yah, I think I agree. We'll have to make up the 2 weeks lost at some
> point, but spreading it out avoids us finding ourselves in a similar
> situation next release. Seems like maybe there may be more work
> being targetted for 2.8 as well.

OK. I have updated 2.7 with the +1week dates (and removed the
note about them being tentative), so let's go with that.

thanks
-- PMM