All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: George Dunlap <dunlapg@umich.edu>, Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>
Subject: Re: Xen 4.12 release planning
Date: Wed, 25 Jul 2018 12:30:15 +0100	[thread overview]
Message-ID: <d5699acb-b110-a629-e0df-593102720c5b@citrix.com> (raw)
In-Reply-To: <CAFLBxZZNzww-8=VqbuaGY4bHpFwxHXtC5J13PKM458yu7VerPg@mail.gmail.com>

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

  reply	other threads:[~2018-07-25 11:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25  7:19 Xen 4.12 release planning Juergen Gross
2018-07-25  8:15 ` Julien Grall
2018-07-25  8:19   ` Andrew Cooper
2018-07-25  9:22     ` Juergen Gross
2018-07-25 11:24       ` George Dunlap
2018-07-25 11:30         ` Andrew Cooper [this message]
2018-07-25 11:34           ` George Dunlap
2018-07-25 11:36             ` Andrew Cooper
2018-07-25 11:34           ` Juergen Gross
2018-07-25 11:37             ` Juergen Gross
2018-07-25 11:39         ` Lars Kurth
2018-07-25 11:45           ` Juergen Gross
2018-07-25 11:51             ` Lars Kurth
2018-07-25 11:58               ` Juergen Gross
2018-07-26 22:13 ` Stefano Stabellini
2018-07-27  7:51   ` Juergen Gross
2018-07-27 10:32     ` Lars Kurth
2018-07-27 10:43       ` Juergen Gross
2018-07-27 15:50         ` Stefano Stabellini
2018-07-27 16:10           ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5699acb-b110-a629-e0df-593102720c5b@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dunlapg@umich.edu \
    --cc=jgross@suse.com \
    --cc=julien.grall@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.