Re: [Xen-devel] Xen 4.12 release planning

[Juergen Gross <jgross@xxxxxxxx>]

On 27/07/18 12:32, Lars Kurth wrote:
> 
> 
>> On 27 Jul 2018, at 08:51, Juergen Gross <jgross@xxxxxxxx
>> <mailto:jgross@xxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel