Xen 4.12 release planning

Xen 4.12 release planning

[Juergen Gross]

Its time to plan the Xen 4.12 release dates.

There have been concerns with the schedule of 6 months between releases,
as this scheme is leading to too many supported versions of Xen at a
time. The needed resources to backport bug fixes and security fixes as
well as doing the tests for all those releases are a limiting factor to
push out the current main release as well as point releases on time.

After some discussions at the Xen developer summit, on xen-devel and
between the committers a slightly longer release cycle of 8 or 9 months
was suggested.

With 18 months of full support and 36 months of security support the
number of concurrent supported releases will be the same with either 8
or 9 months release cycles, so I have chosen an 8 month cycle for now.
Having only 3 possible times in the year for a release will make it
easier to avoid major holiday seasons.

In case there is no objection I'm planning Xen 4.12 with:

* Last posting date: December 14th, 2018
* Hard code freeze: January 11th, 2019
* Release: March 7th, 2019

Release of Xen 4.13 would then be early November 2019, 4.14 at early
July 2020.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Julien Grall]

Hi Juergen,

On 25/07/18 08:19, Juergen Gross wrote:
> Its time to plan the Xen 4.12 release dates.
> 
> There have been concerns with the schedule of 6 months between releases,
> as this scheme is leading to too many supported versions of Xen at a
> time. The needed resources to backport bug fixes and security fixes as
> well as doing the tests for all those releases are a limiting factor to
> push out the current main release as well as point releases on time.
> 
> After some discussions at the Xen developer summit, on xen-devel and
> between the committers a slightly longer release cycle of 8 or 9 months
> was suggested.
> 
> With 18 months of full support and 36 months of security support the
> number of concurrent supported releases will be the same with either 8
> or 9 months release cycles, so I have chosen an 8 month cycle for now.
> Having only 3 possible times in the year for a release will make it
> easier to avoid major holiday seasons. >
> In case there is no objection I'm planning Xen 4.12 with:
> 
> * Last posting date: December 14th, 2018
> * Hard code freeze: January 11th, 2019

In general, you would expect western people to slow down during 
Christmas period and have to deal with a pile of e-mail just after New 
Year. So I think, this is not very convenient period for a code freeze.

I usually take more holidays around Christmas and New Year. For this 
year, I will be on holidays from 21st December until the 13th January. 
This basically means my cut off for Arm patches will be 21st December or 
potentially few days before to avoid having the likely last minute rush.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Andrew Cooper]

On 25/07/2018 09:15, Julien Grall wrote:
> Hi Juergen,
>
> On 25/07/18 08:19, Juergen Gross wrote:
>> Its time to plan the Xen 4.12 release dates.
>>
>> There have been concerns with the schedule of 6 months between releases,
>> as this scheme is leading to too many supported versions of Xen at a
>> time. The needed resources to backport bug fixes and security fixes as
>> well as doing the tests for all those releases are a limiting factor to
>> push out the current main release as well as point releases on time.
>>
>> After some discussions at the Xen developer summit, on xen-devel and
>> between the committers a slightly longer release cycle of 8 or 9 months
>> was suggested.
>>
>> With 18 months of full support and 36 months of security support the
>> number of concurrent supported releases will be the same with either 8
>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>> Having only 3 possible times in the year for a release will make it
>> easier to avoid major holiday seasons. >
>> In case there is no objection I'm planning Xen 4.12 with:
>>
>> * Last posting date: December 14th, 2018
>> * Hard code freeze: January 11th, 2019
>
> In general, you would expect western people to slow down during
> Christmas period and have to deal with a pile of e-mail just after New
> Year. So I think, this is not very convenient period for a code freeze.
>
> I usually take more holidays around Christmas and New Year. For this
> year, I will be on holidays from 21st December until the 13th January.
> This basically means my cut off for Arm patches will be 21st December
> or potentially few days before to avoid having the likely last minute
> rush.

Given that we have decided to switch to a difference cadence, it would
be prudent to work out when the best alignment of an 8-month cadence
would be, rather than having it 8 months from now.  If that means a
one-off shorter or longer cycle for 4.12 then so be it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 25/07/18 10:19, Andrew Cooper wrote:
> On 25/07/2018 09:15, Julien Grall wrote:
>> Hi Juergen,
>>
>> On 25/07/18 08:19, Juergen Gross wrote:
>>> Its time to plan the Xen 4.12 release dates.
>>>
>>> There have been concerns with the schedule of 6 months between releases,
>>> as this scheme is leading to too many supported versions of Xen at a
>>> time. The needed resources to backport bug fixes and security fixes as
>>> well as doing the tests for all those releases are a limiting factor to
>>> push out the current main release as well as point releases on time.
>>>
>>> After some discussions at the Xen developer summit, on xen-devel and
>>> between the committers a slightly longer release cycle of 8 or 9 months
>>> was suggested.
>>>
>>> With 18 months of full support and 36 months of security support the
>>> number of concurrent supported releases will be the same with either 8
>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>> Having only 3 possible times in the year for a release will make it
>>> easier to avoid major holiday seasons. >
>>> In case there is no objection I'm planning Xen 4.12 with:
>>>
>>> * Last posting date: December 14th, 2018
>>> * Hard code freeze: January 11th, 2019
>>
>> In general, you would expect western people to slow down during
>> Christmas period and have to deal with a pile of e-mail just after New
>> Year. So I think, this is not very convenient period for a code freeze.
>>
>> I usually take more holidays around Christmas and New Year. For this
>> year, I will be on holidays from 21st December until the 13th January.
>> This basically means my cut off for Arm patches will be 21st December
>> or potentially few days before to avoid having the likely last minute
>> rush.
> 
> Given that we have decided to switch to a difference cadence, it would
> be prudent to work out when the best alignment of an 8-month cadence
> would be, rather than having it 8 months from now.  If that means a
> one-off shorter or longer cycle for 4.12 then so be it.

The general holiday seasons are:

- Chinese new year (end of January ... mid of February), 2 weeks
- Eastern (end of March ... end of April), only a weak dependency?
- summer (August?), second half of July and first half of September as
  a weak dependency
- Christmas (end of December ... start of January), adding one week as
  a weak dependency

We don't like the planned release to be in or just before a holiday
season. The period between last posting date and freeze should last
2 weeks, the freeze period should last 6 weeks.

In the diagram below I have used a 'X' for a major holiday season and
a 'x' for a weak dependency. The lines below are possible release date
variants just shifted by a weak each to show all possibilities.

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
.ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
.....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f

We can rule out several variants with release dates just before or in a
holiday season:

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
.ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......

Best fit seems to be releasing in first half of March/July/November. The
main clash seems to be Chinese new year in the freeze period, but
avoiding that would mean we'd have to either move into Christmas or
Eastern, or to use a schedule with varying periods.

Please remember that Chinese new year is only 2 weeks long (at varying
dates) so only 2 weeks of the freeze period are hit. Next year the
Chinese new year will be at February 5th.

For my 4.12 plan I've added some extra weeks between last posting date
and release date to accommodate for the holiday seasons, resulting in
my suggestion.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[George Dunlap]

On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
> On 25/07/18 10:19, Andrew Cooper wrote:
>> On 25/07/2018 09:15, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>> Its time to plan the Xen 4.12 release dates.
>>>>
>>>> There have been concerns with the schedule of 6 months between releases,
>>>> as this scheme is leading to too many supported versions of Xen at a
>>>> time. The needed resources to backport bug fixes and security fixes as
>>>> well as doing the tests for all those releases are a limiting factor to
>>>> push out the current main release as well as point releases on time.
>>>>
>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>> was suggested.
>>>>
>>>> With 18 months of full support and 36 months of security support the
>>>> number of concurrent supported releases will be the same with either 8
>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>> Having only 3 possible times in the year for a release will make it
>>>> easier to avoid major holiday seasons. >
>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>
>>>> * Last posting date: December 14th, 2018
>>>> * Hard code freeze: January 11th, 2019
>>>
>>> In general, you would expect western people to slow down during
>>> Christmas period and have to deal with a pile of e-mail just after New
>>> Year. So I think, this is not very convenient period for a code freeze.
>>>
>>> I usually take more holidays around Christmas and New Year. For this
>>> year, I will be on holidays from 21st December until the 13th January.
>>> This basically means my cut off for Arm patches will be 21st December
>>> or potentially few days before to avoid having the likely last minute
>>> rush.
>>
>> Given that we have decided to switch to a difference cadence, it would
>> be prudent to work out when the best alignment of an 8-month cadence
>> would be, rather than having it 8 months from now.  If that means a
>> one-off shorter or longer cycle for 4.12 then so be it.
>
> The general holiday seasons are:
>
> - Chinese new year (end of January ... mid of February), 2 weeks
> - Eastern (end of March ... end of April), only a weak dependency?
> - summer (August?), second half of July and first half of September as
>   a weak dependency
> - Christmas (end of December ... start of January), adding one week as
>   a weak dependency
>
> We don't like the planned release to be in or just before a holiday
> season. The period between last posting date and freeze should last
> 2 weeks, the freeze period should last 6 weeks.
>
> In the diagram below I have used a 'X' for a major holiday season and
> a 'x' for a weak dependency. The lines below are possible release date
> variants just shifted by a weak each to show all possibilities.
>
> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>
> We can rule out several variants with release dates just before or in a
> holiday season:
>
> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>
> Best fit seems to be releasing in first half of March/July/November. The
> main clash seems to be Chinese new year in the freeze period, but
> avoiding that would mean we'd have to either move into Christmas or
> Eastern, or to use a schedule with varying periods.
>
> Please remember that Chinese new year is only 2 weeks long (at varying
> dates) so only 2 weeks of the freeze period are hit. Next year the
> Chinese new year will be at February 5th.
>
> For my 4.12 plan I've added some extra weeks between last posting date
> and release date to accommodate for the holiday seasons, resulting in
> my suggestion.

Thanks for the detailed analysis Juregen.  This seems good to me.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Andrew Cooper]

On 25/07/18 12:24, George Dunlap wrote:
> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
>> On 25/07/18 10:19, Andrew Cooper wrote:
>>> On 25/07/2018 09:15, Julien Grall wrote:
>>>> Hi Juergen,
>>>>
>>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>
>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>> push out the current main release as well as point releases on time.
>>>>>
>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>> was suggested.
>>>>>
>>>>> With 18 months of full support and 36 months of security support the
>>>>> number of concurrent supported releases will be the same with either 8
>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>> Having only 3 possible times in the year for a release will make it
>>>>> easier to avoid major holiday seasons. >
>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>
>>>>> * Last posting date: December 14th, 2018
>>>>> * Hard code freeze: January 11th, 2019
>>>> In general, you would expect western people to slow down during
>>>> Christmas period and have to deal with a pile of e-mail just after New
>>>> Year. So I think, this is not very convenient period for a code freeze.
>>>>
>>>> I usually take more holidays around Christmas and New Year. For this
>>>> year, I will be on holidays from 21st December until the 13th January.
>>>> This basically means my cut off for Arm patches will be 21st December
>>>> or potentially few days before to avoid having the likely last minute
>>>> rush.
>>> Given that we have decided to switch to a difference cadence, it would
>>> be prudent to work out when the best alignment of an 8-month cadence
>>> would be, rather than having it 8 months from now.  If that means a
>>> one-off shorter or longer cycle for 4.12 then so be it.
>> The general holiday seasons are:
>>
>> - Chinese new year (end of January ... mid of February), 2 weeks
>> - Eastern (end of March ... end of April), only a weak dependency?
>> - summer (August?), second half of July and first half of September as
>>   a weak dependency
>> - Christmas (end of December ... start of January), adding one week as
>>   a weak dependency
>>
>> We don't like the planned release to be in or just before a holiday
>> season. The period between last posting date and freeze should last
>> 2 weeks, the freeze period should last 6 weeks.
>>
>> In the diagram below I have used a 'X' for a major holiday season and
>> a 'x' for a weak dependency. The lines below are possible release date
>> variants just shifted by a weak each to show all possibilities.
>>
>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
>> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
>> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
>> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
>> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
>> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
>> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
>> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
>> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
>> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
>> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
>> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
>> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>
>> We can rule out several variants with release dates just before or in a
>> holiday season:
>>
>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>
>> Best fit seems to be releasing in first half of March/July/November. The
>> main clash seems to be Chinese new year in the freeze period, but
>> avoiding that would mean we'd have to either move into Christmas or
>> Eastern, or to use a schedule with varying periods.
>>
>> Please remember that Chinese new year is only 2 weeks long (at varying
>> dates) so only 2 weeks of the freeze period are hit. Next year the
>> Chinese new year will be at February 5th.
>>
>> For my 4.12 plan I've added some extra weeks between last posting date
>> and release date to accommodate for the holiday seasons, resulting in
>> my suggestion.
> Thanks for the detailed analysis Juregen.  This seems good to me.

I think it is also worth staying that we need to work on reducing the
length of the hard freeze date, because as is visible from that diagram,
its basically half the year.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[George Dunlap]

On Wed, Jul 25, 2018 at 12:30 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 25/07/18 12:24, George Dunlap wrote:
>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
>>> On 25/07/18 10:19, Andrew Cooper wrote:
>>>> On 25/07/2018 09:15, Julien Grall wrote:
>>>>> Hi Juergen,
>>>>>
>>>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>>
>>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>>> push out the current main release as well as point releases on time.
>>>>>>
>>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>>> was suggested.
>>>>>>
>>>>>> With 18 months of full support and 36 months of security support the
>>>>>> number of concurrent supported releases will be the same with either 8
>>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>>> Having only 3 possible times in the year for a release will make it
>>>>>> easier to avoid major holiday seasons. >
>>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>>
>>>>>> * Last posting date: December 14th, 2018
>>>>>> * Hard code freeze: January 11th, 2019
>>>>> In general, you would expect western people to slow down during
>>>>> Christmas period and have to deal with a pile of e-mail just after New
>>>>> Year. So I think, this is not very convenient period for a code freeze.
>>>>>
>>>>> I usually take more holidays around Christmas and New Year. For this
>>>>> year, I will be on holidays from 21st December until the 13th January.
>>>>> This basically means my cut off for Arm patches will be 21st December
>>>>> or potentially few days before to avoid having the likely last minute
>>>>> rush.
>>>> Given that we have decided to switch to a difference cadence, it would
>>>> be prudent to work out when the best alignment of an 8-month cadence
>>>> would be, rather than having it 8 months from now.  If that means a
>>>> one-off shorter or longer cycle for 4.12 then so be it.
>>> The general holiday seasons are:
>>>
>>> - Chinese new year (end of January ... mid of February), 2 weeks
>>> - Eastern (end of March ... end of April), only a weak dependency?
>>> - summer (August?), second half of July and first half of September as
>>>   a weak dependency
>>> - Christmas (end of December ... start of January), adding one week as
>>>   a weak dependency
>>>
>>> We don't like the planned release to be in or just before a holiday
>>> season. The period between last posting date and freeze should last
>>> 2 weeks, the freeze period should last 6 weeks.
>>>
>>> In the diagram below I have used a 'X' for a major holiday season and
>>> a 'x' for a weak dependency. The lines below are possible release date
>>> variants just shifted by a weak each to show all possibilities.
>>>
>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
>>> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
>>> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
>>> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
>>> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
>>> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
>>> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
>>> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
>>> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
>>> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
>>> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
>>> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
>>> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>
>>> We can rule out several variants with release dates just before or in a
>>> holiday season:
>>>
>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>
>>> Best fit seems to be releasing in first half of March/July/November. The
>>> main clash seems to be Chinese new year in the freeze period, but
>>> avoiding that would mean we'd have to either move into Christmas or
>>> Eastern, or to use a schedule with varying periods.
>>>
>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>> Chinese new year will be at February 5th.
>>>
>>> For my 4.12 plan I've added some extra weeks between last posting date
>>> and release date to accommodate for the holiday seasons, resulting in
>>> my suggestion.
>> Thanks for the detailed analysis Juregen.  This seems good to me.
>
> I think it is also worth staying that we need to work on reducing the
> length of the hard freeze date, because as is visible from that diagram,
> its basically half the year.

That diagram, however, is basically two years packed into one -- taken
as only a single year it represents a 4-month cycle, not an 8-month
cycle.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 25/07/18 13:30, Andrew Cooper wrote:
> On 25/07/18 12:24, George Dunlap wrote:
>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
>>> On 25/07/18 10:19, Andrew Cooper wrote:
>>>> On 25/07/2018 09:15, Julien Grall wrote:
>>>>> Hi Juergen,
>>>>>
>>>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>>
>>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>>> push out the current main release as well as point releases on time.
>>>>>>
>>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>>> was suggested.
>>>>>>
>>>>>> With 18 months of full support and 36 months of security support the
>>>>>> number of concurrent supported releases will be the same with either 8
>>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>>> Having only 3 possible times in the year for a release will make it
>>>>>> easier to avoid major holiday seasons. >
>>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>>
>>>>>> * Last posting date: December 14th, 2018
>>>>>> * Hard code freeze: January 11th, 2019
>>>>> In general, you would expect western people to slow down during
>>>>> Christmas period and have to deal with a pile of e-mail just after New
>>>>> Year. So I think, this is not very convenient period for a code freeze.
>>>>>
>>>>> I usually take more holidays around Christmas and New Year. For this
>>>>> year, I will be on holidays from 21st December until the 13th January.
>>>>> This basically means my cut off for Arm patches will be 21st December
>>>>> or potentially few days before to avoid having the likely last minute
>>>>> rush.
>>>> Given that we have decided to switch to a difference cadence, it would
>>>> be prudent to work out when the best alignment of an 8-month cadence
>>>> would be, rather than having it 8 months from now.  If that means a
>>>> one-off shorter or longer cycle for 4.12 then so be it.
>>> The general holiday seasons are:
>>>
>>> - Chinese new year (end of January ... mid of February), 2 weeks
>>> - Eastern (end of March ... end of April), only a weak dependency?
>>> - summer (August?), second half of July and first half of September as
>>>   a weak dependency
>>> - Christmas (end of December ... start of January), adding one week as
>>>   a weak dependency
>>>
>>> We don't like the planned release to be in or just before a holiday
>>> season. The period between last posting date and freeze should last
>>> 2 weeks, the freeze period should last 6 weeks.
>>>
>>> In the diagram below I have used a 'X' for a major holiday season and
>>> a 'x' for a weak dependency. The lines below are possible release date
>>> variants just shifted by a weak each to show all possibilities.
>>>
>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
>>> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
>>> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
>>> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
>>> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
>>> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
>>> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
>>> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
>>> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
>>> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
>>> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
>>> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
>>> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>
>>> We can rule out several variants with release dates just before or in a
>>> holiday season:
>>>
>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>
>>> Best fit seems to be releasing in first half of March/July/November. The
>>> main clash seems to be Chinese new year in the freeze period, but
>>> avoiding that would mean we'd have to either move into Christmas or
>>> Eastern, or to use a schedule with varying periods.
>>>
>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>> Chinese new year will be at February 5th.
>>>
>>> For my 4.12 plan I've added some extra weeks between last posting date
>>> and release date to accommodate for the holiday seasons, resulting in
>>> my suggestion.
>> Thanks for the detailed analysis Juregen.  This seems good to me.
> 
> I think it is also worth staying that we need to work on reducing the
> length of the hard freeze date, because as is visible from that diagram,
> its basically half the year.

No, it isn't. It can happen half the year, but in reality it is only
every 9 months (so in one case out of three).

I believe that question is orthogonal to the one about time between
releases. It basically boils down to the question when to branch the new
release off the main trunk.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Andrew Cooper]

On 25/07/18 12:34, George Dunlap wrote:
> On Wed, Jul 25, 2018 at 12:30 PM, Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
>> On 25/07/18 12:24, George Dunlap wrote:
>>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
>>>> On 25/07/18 10:19, Andrew Cooper wrote:
>>>>> On 25/07/2018 09:15, Julien Grall wrote:
>>>>>> Hi Juergen,
>>>>>>
>>>>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>>>
>>>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>>>> push out the current main release as well as point releases on time.
>>>>>>>
>>>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>>>> was suggested.
>>>>>>>
>>>>>>> With 18 months of full support and 36 months of security support the
>>>>>>> number of concurrent supported releases will be the same with either 8
>>>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>>>> Having only 3 possible times in the year for a release will make it
>>>>>>> easier to avoid major holiday seasons. >
>>>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>>>
>>>>>>> * Last posting date: December 14th, 2018
>>>>>>> * Hard code freeze: January 11th, 2019
>>>>>> In general, you would expect western people to slow down during
>>>>>> Christmas period and have to deal with a pile of e-mail just after New
>>>>>> Year. So I think, this is not very convenient period for a code freeze.
>>>>>>
>>>>>> I usually take more holidays around Christmas and New Year. For this
>>>>>> year, I will be on holidays from 21st December until the 13th January.
>>>>>> This basically means my cut off for Arm patches will be 21st December
>>>>>> or potentially few days before to avoid having the likely last minute
>>>>>> rush.
>>>>> Given that we have decided to switch to a difference cadence, it would
>>>>> be prudent to work out when the best alignment of an 8-month cadence
>>>>> would be, rather than having it 8 months from now.  If that means a
>>>>> one-off shorter or longer cycle for 4.12 then so be it.
>>>> The general holiday seasons are:
>>>>
>>>> - Chinese new year (end of January ... mid of February), 2 weeks
>>>> - Eastern (end of March ... end of April), only a weak dependency?
>>>> - summer (August?), second half of July and first half of September as
>>>>   a weak dependency
>>>> - Christmas (end of December ... start of January), adding one week as
>>>>   a weak dependency
>>>>
>>>> We don't like the planned release to be in or just before a holiday
>>>> season. The period between last posting date and freeze should last
>>>> 2 weeks, the freeze period should last 6 weeks.
>>>>
>>>> In the diagram below I have used a 'X' for a major holiday season and
>>>> a 'x' for a weak dependency. The lines below are possible release date
>>>> variants just shifted by a weak each to show all possibilities.
>>>>
>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
>>>> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
>>>> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
>>>> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
>>>> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
>>>> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
>>>> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
>>>> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
>>>> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
>>>> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
>>>> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
>>>> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
>>>> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
>>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>>
>>>> We can rule out several variants with release dates just before or in a
>>>> holiday season:
>>>>
>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>>
>>>> Best fit seems to be releasing in first half of March/July/November. The
>>>> main clash seems to be Chinese new year in the freeze period, but
>>>> avoiding that would mean we'd have to either move into Christmas or
>>>> Eastern, or to use a schedule with varying periods.
>>>>
>>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>>> Chinese new year will be at February 5th.
>>>>
>>>> For my 4.12 plan I've added some extra weeks between last posting date
>>>> and release date to accommodate for the holiday seasons, resulting in
>>>> my suggestion.
>>> Thanks for the detailed analysis Juregen.  This seems good to me.
>> I think it is also worth staying that we need to work on reducing the
>> length of the hard freeze date, because as is visible from that diagram,
>> its basically half the year.
> That diagram, however, is basically two years packed into one -- taken
> as only a single year it represents a 4-month cycle, not an 8-month
> cycle.

Oh - of course.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 25/07/18 13:34, Juergen Gross wrote:
> On 25/07/18 13:30, Andrew Cooper wrote:
>> On 25/07/18 12:24, George Dunlap wrote:
>>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com> wrote:
>>>> On 25/07/18 10:19, Andrew Cooper wrote:
>>>>> On 25/07/2018 09:15, Julien Grall wrote:
>>>>>> Hi Juergen,
>>>>>>
>>>>>> On 25/07/18 08:19, Juergen Gross wrote:
>>>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>>>
>>>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>>>> push out the current main release as well as point releases on time.
>>>>>>>
>>>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>>>> was suggested.
>>>>>>>
>>>>>>> With 18 months of full support and 36 months of security support the
>>>>>>> number of concurrent supported releases will be the same with either 8
>>>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>>>> Having only 3 possible times in the year for a release will make it
>>>>>>> easier to avoid major holiday seasons. >
>>>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>>>
>>>>>>> * Last posting date: December 14th, 2018
>>>>>>> * Hard code freeze: January 11th, 2019
>>>>>> In general, you would expect western people to slow down during
>>>>>> Christmas period and have to deal with a pile of e-mail just after New
>>>>>> Year. So I think, this is not very convenient period for a code freeze.
>>>>>>
>>>>>> I usually take more holidays around Christmas and New Year. For this
>>>>>> year, I will be on holidays from 21st December until the 13th January.
>>>>>> This basically means my cut off for Arm patches will be 21st December
>>>>>> or potentially few days before to avoid having the likely last minute
>>>>>> rush.
>>>>> Given that we have decided to switch to a difference cadence, it would
>>>>> be prudent to work out when the best alignment of an 8-month cadence
>>>>> would be, rather than having it 8 months from now.  If that means a
>>>>> one-off shorter or longer cycle for 4.12 then so be it.
>>>> The general holiday seasons are:
>>>>
>>>> - Chinese new year (end of January ... mid of February), 2 weeks
>>>> - Eastern (end of March ... end of April), only a weak dependency?
>>>> - summer (August?), second half of July and first half of September as
>>>>   a weak dependency
>>>> - Christmas (end of December ... start of January), adding one week as
>>>>   a weak dependency
>>>>
>>>> We don't like the planned release to be in or just before a holiday
>>>> season. The period between last posting date and freeze should last
>>>> 2 weeks, the freeze period should last 6 weeks.
>>>>
>>>> In the diagram below I have used a 'X' for a major holiday season and
>>>> a 'x' for a weak dependency. The lines below are possible release date
>>>> variants just shifted by a weak each to show all possibilities.
>>>>
>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>> ..ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.....
>>>> ...ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR....
>>>> ....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR...
>>>> .....ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR..
>>>> ......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.
>>>> .......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR
>>>> R.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFFF
>>>> FR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFFF
>>>> FFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFFF
>>>> FFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFFF
>>>> FFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffFF
>>>> FFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ffF
>>>> FFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......ff
>>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>>
>>>> We can rule out several variants with release dates just before or in a
>>>> holiday season:
>>>>
>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>>
>>>> Best fit seems to be releasing in first half of March/July/November. The
>>>> main clash seems to be Chinese new year in the freeze period, but
>>>> avoiding that would mean we'd have to either move into Christmas or
>>>> Eastern, or to use a schedule with varying periods.
>>>>
>>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>>> Chinese new year will be at February 5th.
>>>>
>>>> For my 4.12 plan I've added some extra weeks between last posting date
>>>> and release date to accommodate for the holiday seasons, resulting in
>>>> my suggestion.
>>> Thanks for the detailed analysis Juregen.  This seems good to me.
>>
>> I think it is also worth staying that we need to work on reducing the
>> length of the hard freeze date, because as is visible from that diagram,
>> its basically half the year.
> 
> No, it isn't. It can happen half the year, but in reality it is only
> every 9 months (so in one case out of three).

Aarg, of course this should be: every 8 months (so always skipping one
case).


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1992 bytes --]



> On 25 Jul 2018, at 12:24, George Dunlap <dunlapg@umich.edu> wrote:
> 
> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com <mailto:jgross@suse.com>> wrote:
>> 
>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>> 
>> We can rule out several variants with release dates just before or in a
>> holiday season:
>> 
>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>> 
>> Best fit seems to be releasing in first half of March/July/November. The
>> main clash seems to be Chinese new year in the freeze period, but
>> avoiding that would mean we'd have to either move into Christmas or
>> Eastern, or to use a schedule with varying periods.
>> 
>> Please remember that Chinese new year is only 2 weeks long (at varying
>> dates) so only 2 weeks of the freeze period are hit. Next year the
>> Chinese new year will be at February 5th.
>> 
>> For my 4.12 plan I've added some extra weeks between last posting date
>> and release date to accommodate for the holiday seasons, resulting in
>> my suggestion.
> 
> Thanks for the detailed analysis Juregen.  This seems good to me.
> 
> -George

This looks good to me also. To address Julien's concerns, we could also consider an earlier Last posting date/Hard code freeze date for Arm related code to work around Julien's holiday plans. I think this would be entirely OK and set expectations of contributors accordingly. But maybe this is not necessary if Julien and Stefano can agree a work split somehow. 

Alternatively we could communicate absences of key reviewers say in November to set expectations of contributors for the final stretch of the release cycle. In other words, if a key reviewer is away, then contributors will need to get series into good shape before their reviewers go on vacation. 

Regards
Lars


[-- Attachment #1.2: Type: text/html, Size: 6728 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 25/07/18 13:39, Lars Kurth wrote:
> 
> 
>> On 25 Jul 2018, at 12:24, George Dunlap <dunlapg@umich.edu
>> <mailto:dunlapg@umich.edu>> wrote:
>>
>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com
>> <mailto:jgross@suse.com>> wrote:
>>>
>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>
>>> We can rule out several variants with release dates just before or in a
>>> holiday season:
>>>
>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>
>>> Best fit seems to be releasing in first half of March/July/November. The
>>> main clash seems to be Chinese new year in the freeze period, but
>>> avoiding that would mean we'd have to either move into Christmas or
>>> Eastern, or to use a schedule with varying periods.
>>>
>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>> Chinese new year will be at February 5th.
>>>
>>> For my 4.12 plan I've added some extra weeks between last posting date
>>> and release date to accommodate for the holiday seasons, resulting in
>>> my suggestion.
>>
>> Thanks for the detailed analysis Juregen.  This seems good to me.
>>
>> -George
> 
> This looks good to me also. To address Julien's concerns, we could also
> consider an earlier Last posting date/Hard code freeze date for Arm
> related code to work around Julien's holiday plans. I think this would
> be entirely OK and set expectations of contributors accordingly. But
> maybe this is not necessary if Julien and Stefano can agree a work split
> somehow. 
> 
> Alternatively we could communicate absences of key reviewers say in
> November to set expectations of contributors for the final stretch of
> the release cycle. In other words, if a key reviewer is away, then
> contributors will need to get series into good shape before their
> reviewers go on vacation. 

I like that idea. Lets expand it to key persons (i.e. release manager,
release technician, community manager, key reviewers).


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Lars Kurth]

> On 25 Jul 2018, at 12:45, Juergen Gross <jgross@suse.com> wrote:
> 
> On 25/07/18 13:39, Lars Kurth wrote:
>> 
>> 
>>> On 25 Jul 2018, at 12:24, George Dunlap <dunlapg@umich.edu
>>> <mailto:dunlapg@umich.edu>> wrote:
>>> 
>>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com
>>> <mailto:jgross@suse.com>> wrote:
>>>> 
>>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>> 
>>>> We can rule out several variants with release dates just before or in a
>>>> holiday season:
>>>> 
>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>> 
>>>> Best fit seems to be releasing in first half of March/July/November. The
>>>> main clash seems to be Chinese new year in the freeze period, but
>>>> avoiding that would mean we'd have to either move into Christmas or
>>>> Eastern, or to use a schedule with varying periods.
>>>> 
>>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>>> Chinese new year will be at February 5th.
>>>> 
>>>> For my 4.12 plan I've added some extra weeks between last posting date
>>>> and release date to accommodate for the holiday seasons, resulting in
>>>> my suggestion.
>>> 
>>> Thanks for the detailed analysis Juregen.  This seems good to me.
>>> 
>>> -George
>> 
>> This looks good to me also. To address Julien's concerns, we could also
>> consider an earlier Last posting date/Hard code freeze date for Arm
>> related code to work around Julien's holiday plans. I think this would
>> be entirely OK and set expectations of contributors accordingly. But
>> maybe this is not necessary if Julien and Stefano can agree a work split
>> somehow. 
>> 
>> Alternatively we could communicate absences of key reviewers say in
>> November to set expectations of contributors for the final stretch of
>> the release cycle. In other words, if a key reviewer is away, then
>> contributors will need to get series into good shape before their
>> reviewers go on vacation. 
> 
> I like that idea. Lets expand it to key persons (i.e. release manager,
> release technician, community manager, key reviewers).

We should probably add this to the Release manager TODO list, such that we don't forget when the time comes. The same principle could apply to other holiday periods as well.

Lars




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 25/07/18 13:51, Lars Kurth wrote:
> 
> 
>> On 25 Jul 2018, at 12:45, Juergen Gross <jgross@suse.com> wrote:
>>
>> On 25/07/18 13:39, Lars Kurth wrote:
>>>
>>>
>>>> On 25 Jul 2018, at 12:24, George Dunlap <dunlapg@umich.edu
>>>> <mailto:dunlapg@umich.edu>> wrote:
>>>>
>>>> On Wed, Jul 25, 2018 at 10:22 AM, Juergen Gross <jgross@suse.com
>>>> <mailto:jgross@suse.com>> wrote:
>>>>>
>>>>> fFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......f
>>>>>
>>>>> We can rule out several variants with release dates just before or in a
>>>>> holiday season:
>>>>>
>>>>> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
>>>>> Xx.XXXXX...xxxx...........xxXXXXx..............X      holidays
>>>>> ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR.......
>>>>> .ffFFFFFFR.......ffFFFFFFR.......ffFFFFFFR......
>>>>>
>>>>> Best fit seems to be releasing in first half of March/July/November. The
>>>>> main clash seems to be Chinese new year in the freeze period, but
>>>>> avoiding that would mean we'd have to either move into Christmas or
>>>>> Eastern, or to use a schedule with varying periods.
>>>>>
>>>>> Please remember that Chinese new year is only 2 weeks long (at varying
>>>>> dates) so only 2 weeks of the freeze period are hit. Next year the
>>>>> Chinese new year will be at February 5th.
>>>>>
>>>>> For my 4.12 plan I've added some extra weeks between last posting date
>>>>> and release date to accommodate for the holiday seasons, resulting in
>>>>> my suggestion.
>>>>
>>>> Thanks for the detailed analysis Juregen.  This seems good to me.
>>>>
>>>> -George
>>>
>>> This looks good to me also. To address Julien's concerns, we could also
>>> consider an earlier Last posting date/Hard code freeze date for Arm
>>> related code to work around Julien's holiday plans. I think this would
>>> be entirely OK and set expectations of contributors accordingly. But
>>> maybe this is not necessary if Julien and Stefano can agree a work split
>>> somehow. 
>>>
>>> Alternatively we could communicate absences of key reviewers say in
>>> November to set expectations of contributors for the final stretch of
>>> the release cycle. In other words, if a key reviewer is away, then
>>> contributors will need to get series into good shape before their
>>> reviewers go on vacation. 
>>
>> I like that idea. Lets expand it to key persons (i.e. release manager,
>> release technician, community manager, key reviewers).
> 
> We should probably add this to the Release manager TODO list, such that we don't forget when the time comes. The same principle could apply to other holiday periods as well.

I would rather tie that to the point in the release process. There might
be planned vacations at other times, too.

I'll send a patch for the release management doc.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Stefano Stabellini]

On Wed, 25 Jul 2018, Juergen Gross wrote:
> Its time to plan the Xen 4.12 release dates.
> 
> There have been concerns with the schedule of 6 months between releases,
> as this scheme is leading to too many supported versions of Xen at a
> time. The needed resources to backport bug fixes and security fixes as
> well as doing the tests for all those releases are a limiting factor to
> push out the current main release as well as point releases on time.
> 
> After some discussions at the Xen developer summit, on xen-devel and
> between the committers a slightly longer release cycle of 8 or 9 months
> was suggested.
> 
> With 18 months of full support and 36 months of security support the
> number of concurrent supported releases will be the same with either 8
> or 9 months release cycles, so I have chosen an 8 month cycle for now.
> Having only 3 possible times in the year for a release will make it
> easier to avoid major holiday seasons.
> 
> In case there is no objection I'm planning Xen 4.12 with:
> 
> * Last posting date: December 14th, 2018
> * Hard code freeze: January 11th, 2019
> * Release: March 7th, 2019
> 
> Release of Xen 4.13 would then be early November 2019, 4.14 at early
> July 2020.

Given the holdidays season (it is not just Julien going on vacation but
pretty much everybody), wouldn't it be better to move the hard code
freeze by a couple of weeks? For instance Jan 25th? We can still keep
the release date as Mar 7th, there should be still enough time?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 00:13, Stefano Stabellini wrote:
> On Wed, 25 Jul 2018, Juergen Gross wrote:
>> Its time to plan the Xen 4.12 release dates.
>>
>> There have been concerns with the schedule of 6 months between releases,
>> as this scheme is leading to too many supported versions of Xen at a
>> time. The needed resources to backport bug fixes and security fixes as
>> well as doing the tests for all those releases are a limiting factor to
>> push out the current main release as well as point releases on time.
>>
>> After some discussions at the Xen developer summit, on xen-devel and
>> between the committers a slightly longer release cycle of 8 or 9 months
>> was suggested.
>>
>> With 18 months of full support and 36 months of security support the
>> number of concurrent supported releases will be the same with either 8
>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>> Having only 3 possible times in the year for a release will make it
>> easier to avoid major holiday seasons.
>>
>> In case there is no objection I'm planning Xen 4.12 with:
>>
>> * Last posting date: December 14th, 2018
>> * Hard code freeze: January 11th, 2019
>> * Release: March 7th, 2019
>>
>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>> July 2020.
> 
> Given the holdidays season (it is not just Julien going on vacation but
> pretty much everybody), wouldn't it be better to move the hard code
> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> the release date as Mar 7th, there should be still enough time?

I don't think planning with a 6 week freeze period is a good idea. The
last releases took longer than 2 months.

We could slip the complete release by 2 weeks, of course. In this case
I'd move the last posting date to January. So something like:

* Last posting date: January 11th, 2019
* Hard code freeze: January 25th, 2019
* Release: March 21st, 2019

Risks for that schedule are:
- last posting date short after holiday season - is that really a
  problem?
- Chinese new year rather soon after start of freeze period
- planned release date rather close to eastern

Opinions?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 3178 bytes --]



> On 27 Jul 2018, at 08:51, Juergen Gross <jgross@suse.com> wrote:
> 
> On 27/07/18 00:13, Stefano Stabellini wrote:
>> On Wed, 25 Jul 2018, Juergen Gross wrote:
>>> Its time to plan the Xen 4.12 release dates.
>>> 
>>> There have been concerns with the schedule of 6 months between releases,
>>> as this scheme is leading to too many supported versions of Xen at a
>>> time. The needed resources to backport bug fixes and security fixes as
>>> well as doing the tests for all those releases are a limiting factor to
>>> push out the current main release as well as point releases on time.
>>> 
>>> After some discussions at the Xen developer summit, on xen-devel and
>>> between the committers a slightly longer release cycle of 8 or 9 months
>>> was suggested.
>>> 
>>> With 18 months of full support and 36 months of security support the
>>> number of concurrent supported releases will be the same with either 8
>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>> Having only 3 possible times in the year for a release will make it
>>> easier to avoid major holiday seasons.
>>> 
>>> In case there is no objection I'm planning Xen 4.12 with:
>>> 
>>> * Last posting date: December 14th, 2018
>>> * Hard code freeze: January 11th, 2019
>>> * Release: March 7th, 2019
>>> 
>>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>>> July 2020.
>> 
>> Given the holdidays season (it is not just Julien going on vacation but
>> pretty much everybody), wouldn't it be better to move the hard code
>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
>> the release date as Mar 7th, there should be still enough time?
> 
> I don't think planning with a 6 week freeze period is a good idea. The
> last releases took longer than 2 months.
> 
> We could slip the complete release by 2 weeks, of course. In this case
> I'd move the last posting date to January. So something like:
> 
> * Last posting date: January 11th, 2019
> * Hard code freeze: January 25th, 2019
> * Release: March 21st, 2019

Another alternative would be to move the dates backwards rather than forward. The 4.12 development window effectively opened 21-06-18, so a last posting data and hard code freeze before Xmas should be OK. Then assume that there won't be RC's for at last 2 (maybe 3) weeks during the winter holidays. But as long as someone is there to keep an eye on OSSTEST and to do a force push and build an RC1 before Xmas that may be OK: but it would probably still be OK if RC1 slipped until just after New Years Eve.

> Risks for that schedule are:
> - last posting date short after holiday season - is that really a
>  problem?
> - Chinese new year rather soon after start of freeze period
> - planned release date rather close to eastern
> 
> Opinions?

With this in mind. The only problem is that there will be Chinese New Year for some of the late to middle RCs ... Looking at possible RC dates
RC1: wk Jan 1st 
RC2: wk Jan 8th
RC3: wk Jan 15th
RC4: wk Jan 22nd
RC5: wk Jan 29th
RC6: wk Feb 5th (Chinese New Year)
RC7: wk Feb 12th
RC8: wk Feb 19th

Lars

 

[-- Attachment #1.2: Type: text/html, Size: 12484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 12:32, Lars Kurth wrote:
> 
> 
>> On 27 Jul 2018, at 08:51, Juergen Gross <jgross@suse.com
>> <mailto:jgross@suse.com>> wrote:
>>
>> On 27/07/18 00:13, Stefano Stabellini wrote:
>>> On Wed, 25 Jul 2018, Juergen Gross wrote:
>>>> Its time to plan the Xen 4.12 release dates.
>>>>
>>>> There have been concerns with the schedule of 6 months between releases,
>>>> as this scheme is leading to too many supported versions of Xen at a
>>>> time. The needed resources to backport bug fixes and security fixes as
>>>> well as doing the tests for all those releases are a limiting factor to
>>>> push out the current main release as well as point releases on time.
>>>>
>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>> was suggested.
>>>>
>>>> With 18 months of full support and 36 months of security support the
>>>> number of concurrent supported releases will be the same with either 8
>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>> Having only 3 possible times in the year for a release will make it
>>>> easier to avoid major holiday seasons.
>>>>
>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>
>>>> * Last posting date: December 14th, 2018
>>>> * Hard code freeze: January 11th, 2019
>>>> * Release: March 7th, 2019
>>>>
>>>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>>>> July 2020.
>>>
>>> Given the holdidays season (it is not just Julien going on vacation but
>>> pretty much everybody), wouldn't it be better to move the hard code
>>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
>>> the release date as Mar 7th, there should be still enough time?
>>
>> I don't think planning with a 6 week freeze period is a good idea. The
>> last releases took longer than 2 months.
>>
>> We could slip the complete release by 2 weeks, of course. In this case
>> I'd move the last posting date to January. So something like:
>>
>> * Last posting date: January 11th, 2019
>> * Hard code freeze: January 25th, 2019
>> * Release: March 21st, 2019
> 
> Another alternative would be to move the dates backwards rather than
> forward. The 4.12 development window effectively opened 21-06-18, so a
> last posting data and hard code freeze before Xmas should be OK. Then
> assume that there won't be RC's for at last 2 (maybe 3) weeks during the
> winter holidays. But as long as someone is there to keep an eye on
> OSSTEST and to do a force push and build an RC1 before Xmas that may be
> OK: but it would probably still be OK if RC1 slipped until just after
> New Years Eve.

You are neglecting that the reason for no RC directly after the freeze
is normally due to bugs. And those need to be found and fixed by
someone. So putting the freeze directly before a holiday season just
makes the freeze longer without any major advantage.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Stefano Stabellini]

On Fri, 27 Jul 2018, Juergen Gross wrote:
> On 27/07/18 12:32, Lars Kurth wrote:
> > 
> > 
> >> On 27 Jul 2018, at 08:51, Juergen Gross <jgross@suse.com
> >> <mailto:jgross@suse.com>> wrote:
> >>
> >> On 27/07/18 00:13, Stefano Stabellini wrote:
> >>> On Wed, 25 Jul 2018, Juergen Gross wrote:
> >>>> Its time to plan the Xen 4.12 release dates.
> >>>>
> >>>> There have been concerns with the schedule of 6 months between releases,
> >>>> as this scheme is leading to too many supported versions of Xen at a
> >>>> time. The needed resources to backport bug fixes and security fixes as
> >>>> well as doing the tests for all those releases are a limiting factor to
> >>>> push out the current main release as well as point releases on time.
> >>>>
> >>>> After some discussions at the Xen developer summit, on xen-devel and
> >>>> between the committers a slightly longer release cycle of 8 or 9 months
> >>>> was suggested.
> >>>>
> >>>> With 18 months of full support and 36 months of security support the
> >>>> number of concurrent supported releases will be the same with either 8
> >>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
> >>>> Having only 3 possible times in the year for a release will make it
> >>>> easier to avoid major holiday seasons.
> >>>>
> >>>> In case there is no objection I'm planning Xen 4.12 with:
> >>>>
> >>>> * Last posting date: December 14th, 2018
> >>>> * Hard code freeze: January 11th, 2019
> >>>> * Release: March 7th, 2019
> >>>>
> >>>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
> >>>> July 2020.
> >>>
> >>> Given the holdidays season (it is not just Julien going on vacation but
> >>> pretty much everybody), wouldn't it be better to move the hard code
> >>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> >>> the release date as Mar 7th, there should be still enough time?
> >>
> >> I don't think planning with a 6 week freeze period is a good idea. The
> >> last releases took longer than 2 months.
> >>
> >> We could slip the complete release by 2 weeks, of course. In this case
> >> I'd move the last posting date to January. So something like:
> >>
> >> * Last posting date: January 11th, 2019
> >> * Hard code freeze: January 25th, 2019
> >> * Release: March 21st, 2019
> > 
> > Another alternative would be to move the dates backwards rather than
> > forward. The 4.12 development window effectively opened 21-06-18, so a
> > last posting data and hard code freeze before Xmas should be OK. Then
> > assume that there won't be RC's for at last 2 (maybe 3) weeks during the
> > winter holidays. But as long as someone is there to keep an eye on
> > OSSTEST and to do a force push and build an RC1 before Xmas that may be
> > OK: but it would probably still be OK if RC1 slipped until just after
> > New Years Eve.
> 
> You are neglecting that the reason for no RC directly after the freeze
> is normally due to bugs. And those need to be found and fixed by
> someone. So putting the freeze directly before a holiday season just
> makes the freeze longer without any major advantage.

There is no silver bullet here, it is up to you. I'd say that given the
current set of maintainers that we have, I think that overlapping with
Chinese New Year is less damaging than overlapping with Christmas. So
I'd move the dates backward by 2 weeks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 17:50, Stefano Stabellini wrote:
> On Fri, 27 Jul 2018, Juergen Gross wrote:
>> On 27/07/18 12:32, Lars Kurth wrote:
>>>
>>>
>>>> On 27 Jul 2018, at 08:51, Juergen Gross <jgross@suse.com
>>>> <mailto:jgross@suse.com>> wrote:
>>>>
>>>> On 27/07/18 00:13, Stefano Stabellini wrote:
>>>>> On Wed, 25 Jul 2018, Juergen Gross wrote:
>>>>>> Its time to plan the Xen 4.12 release dates.
>>>>>>
>>>>>> There have been concerns with the schedule of 6 months between releases,
>>>>>> as this scheme is leading to too many supported versions of Xen at a
>>>>>> time. The needed resources to backport bug fixes and security fixes as
>>>>>> well as doing the tests for all those releases are a limiting factor to
>>>>>> push out the current main release as well as point releases on time.
>>>>>>
>>>>>> After some discussions at the Xen developer summit, on xen-devel and
>>>>>> between the committers a slightly longer release cycle of 8 or 9 months
>>>>>> was suggested.
>>>>>>
>>>>>> With 18 months of full support and 36 months of security support the
>>>>>> number of concurrent supported releases will be the same with either 8
>>>>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>>>>> Having only 3 possible times in the year for a release will make it
>>>>>> easier to avoid major holiday seasons.
>>>>>>
>>>>>> In case there is no objection I'm planning Xen 4.12 with:
>>>>>>
>>>>>> * Last posting date: December 14th, 2018
>>>>>> * Hard code freeze: January 11th, 2019
>>>>>> * Release: March 7th, 2019
>>>>>>
>>>>>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>>>>>> July 2020.
>>>>>
>>>>> Given the holdidays season (it is not just Julien going on vacation but
>>>>> pretty much everybody), wouldn't it be better to move the hard code
>>>>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
>>>>> the release date as Mar 7th, there should be still enough time?
>>>>
>>>> I don't think planning with a 6 week freeze period is a good idea. The
>>>> last releases took longer than 2 months.
>>>>
>>>> We could slip the complete release by 2 weeks, of course. In this case
>>>> I'd move the last posting date to January. So something like:
>>>>
>>>> * Last posting date: January 11th, 2019
>>>> * Hard code freeze: January 25th, 2019
>>>> * Release: March 21st, 2019
>>>
>>> Another alternative would be to move the dates backwards rather than
>>> forward. The 4.12 development window effectively opened 21-06-18, so a
>>> last posting data and hard code freeze before Xmas should be OK. Then
>>> assume that there won't be RC's for at last 2 (maybe 3) weeks during the
>>> winter holidays. But as long as someone is there to keep an eye on
>>> OSSTEST and to do a force push and build an RC1 before Xmas that may be
>>> OK: but it would probably still be OK if RC1 slipped until just after
>>> New Years Eve.
>>
>> You are neglecting that the reason for no RC directly after the freeze
>> is normally due to bugs. And those need to be found and fixed by
>> someone. So putting the freeze directly before a holiday season just
>> makes the freeze longer without any major advantage.
> 
> There is no silver bullet here, it is up to you. I'd say that given the
> current set of maintainers that we have, I think that overlapping with
> Chinese New Year is less damaging than overlapping with Christmas. So
> I'd move the dates backward by 2 weeks.

Just for the records:

Via IRC we (Stefano and me) discussed the release schedule and now he is
fine with my initial proposal:

* Last posting date: December 14th, 2018
* Hard code freeze: January 11th, 2019
* Release: March 7th, 2019

with the addendum that depending on vacation plans over Christmas e.g.
patch series needing an Ack from arm maintainers might have an earlier
last posting date.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel