Re: Xen 4.12 release planning

[Juergen Gross <jgross@suse.com>]

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