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 <[email protected] >>>> <mailto:[email protected]>> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
