[Qemu-devel] proposed schedule for 2.11 release

[Qemu-devel] proposed schedule for 2.11 release

[Peter Maydell]

OK, here's a strawman proposal for the 2.11 release cycle,
based on aiming for a 5 Dec release date and working backwards
with the same cadence as 2.10.

2017-10-31 Soft freeze -- all feature changes must already be in a
           pull request that's been sent to the mailing list
2017-11-07 Hard freeze, tag rc0
2017-11-14 Tag rc1
2017-11-21 Tag rc2
2017-11-28 Tag rc3
2017-12-05 Release (or rc4 if we need it)
2017-12-12 Release if we needed an rc4


That makes softfreeze in 3 weeks time. I'd rather not push
the times back any further because we end up in serious
risk of running into the christmas holiday period.

(I'm still unconvinced by the 1-week softfreeze schedule.)

thanks
-- PMM

Re: [Qemu-devel] proposed schedule for 2.11 release

[Daniel P. Berrange]

On Tue, Oct 10, 2017 at 03:07:26PM +0100, Peter Maydell wrote:
> OK, here's a strawman proposal for the 2.11 release cycle,
> based on aiming for a 5 Dec release date and working backwards
> with the same cadence as 2.10.
> 
> 2017-10-31 Soft freeze -- all feature changes must already be in a
>            pull request that's been sent to the mailing list
> 2017-11-07 Hard freeze, tag rc0
> 2017-11-14 Tag rc1
> 2017-11-21 Tag rc2
> 2017-11-28 Tag rc3
> 2017-12-05 Release (or rc4 if we need it)
> 2017-12-12 Release if we needed an rc4
> 
> 
> That makes softfreeze in 3 weeks time. I'd rather not push
> the times back any further because we end up in serious
> risk of running into the christmas holiday period.

Soft freeze date is not great from a KVM Forum timing POV - the 31st is
likely to be a travel day for most of the Red Hat devs.

That said I don't see a much nicer alternative, since giving two weeks
grace before xmas is good, to allow time for slippage in worst case
scenarios.

I guess, it in effect just means that most soft freeze work will want to
be front loaded in the next 2 weeks before KVM Forum travel starts impacting
working time.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] proposed schedule for 2.11 release

[Paolo Bonzini]

On 10/10/2017 18:10, Daniel P. Berrange wrote:
> On Tue, Oct 10, 2017 at 03:07:26PM +0100, Peter Maydell wrote:
>> OK, here's a strawman proposal for the 2.11 release cycle,
>> based on aiming for a 5 Dec release date and working backwards
>> with the same cadence as 2.10.
>>
>> 2017-10-31 Soft freeze -- all feature changes must already be in a
>>            pull request that's been sent to the mailing list
>> 2017-11-07 Hard freeze, tag rc0
>> 2017-11-14 Tag rc1
>> 2017-11-21 Tag rc2
>> 2017-11-28 Tag rc3
>> 2017-12-05 Release (or rc4 if we need it)
>> 2017-12-12 Release if we needed an rc4
>>
>> That makes softfreeze in 3 weeks time. I'd rather not push
>> the times back any further because we end up in serious
>> risk of running into the christmas holiday period.
> 
> Soft freeze date is not great from a KVM Forum timing POV - the 31st is
> likely to be a travel day for most of the Red Hat devs.

Might as well have soft freeze on Oct 24 (and keep hard freeze on Nov
7)...  Non-maintainers posting patches on the Oct 24-31 week probably
wouldn't have them included in 2.11 anyway.

Paolo

> That said I don't see a much nicer alternative, since giving two weeks
> grace before xmas is good, to allow time for slippage in worst case
> scenarios.
> 
> I guess, it in effect just means that most soft freeze work will want to
> be front loaded in the next 2 weeks before KVM Forum travel starts impacting
> working time.
> 
> Regards,
> Daniel
> 

Re: [Qemu-devel] proposed schedule for 2.11 release

[Peter Maydell]

On 10 October 2017 at 17:26, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/10/2017 18:10, Daniel P. Berrange wrote:
>> On Tue, Oct 10, 2017 at 03:07:26PM +0100, Peter Maydell wrote:
>>> OK, here's a strawman proposal for the 2.11 release cycle,
>>> based on aiming for a 5 Dec release date and working backwards
>>> with the same cadence as 2.10.
>>>
>>> 2017-10-31 Soft freeze -- all feature changes must already be in a
>>>            pull request that's been sent to the mailing list
>>> 2017-11-07 Hard freeze, tag rc0
>>> 2017-11-14 Tag rc1
>>> 2017-11-21 Tag rc2
>>> 2017-11-28 Tag rc3
>>> 2017-12-05 Release (or rc4 if we need it)
>>> 2017-12-12 Release if we needed an rc4
>>>
>>> That makes softfreeze in 3 weeks time. I'd rather not push
>>> the times back any further because we end up in serious
>>> risk of running into the christmas holiday period.
>>
>> Soft freeze date is not great from a KVM Forum timing POV - the 31st is
>> likely to be a travel day for most of the Red Hat devs.
>
> Might as well have soft freeze on Oct 24 (and keep hard freeze on Nov
> 7)...  Non-maintainers posting patches on the Oct 24-31 week probably
> wouldn't have them included in 2.11 anyway.

Hmm, I'd forgotten that KVM Forum dates would mess this up.
I'm going to be travelling/at the conference for the 23-27th
week, so I can't guarantee that I'll be able to apply any pull
requests then. But I will be back for the 30th, so I'd
rather not officially set the soft freeze date to the 24th.
Maintainers who are going to be away then will just, as
Daniel suggests, want to plan ahead to have got their
pull requests on list.

thanks
-- PMM