[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen release cycle revisited

On 12/18/2017 04:10 PM, Juergen Gross wrote:
> On 18/12/17 16:57, Julien Grall wrote:
>> Hi George,
>> On 18/12/17 14:56, George Dunlap wrote:
>>> On Fri, Dec 15, 2017 at 2:54 PM, Juergen Gross <jgross@xxxxxxxx> wrote:
>>>> On 14/12/17 14:13, Juergen Gross wrote:
>>>>> On 14/12/17 13:43, Julien Grall wrote:
>>>>>> On 14/12/17 11:38, Juergen Gross wrote:
>>>>>>> On 14/12/17 12:28, Julien Grall wrote:
>>>>>>>> On 14/12/17 07:56, Juergen Gross wrote:
>>>>>>>>> Hi all,
>>>>>>>> Hi Juergen,
>>>>>>>> I would recommend to CC committers on that thread, so your thread
>>>>>>>> don't
>>>>>>>> get lost in the xen-devel meanders :).
>>>>>>>>> with 4.10 more or less finished it is time to plan for the next
>>>>>>>>> release
>>>>>>>>> 4.11. Since 4.7 we are using a 6 month release cycle [1]
>>>>>>>>> targeting to
>>>>>>>>> release in June and December.
>>>>>>>>> While this worked reasonably well for 4.7, 4.8 and 4.9 we had some
>>>>>>>>> difficulties with 4.10: bad luck with security patch timing
>>>>>>>>> shifted the
>>>>>>>>> 4.10 release more towards mid of December. Doing thorough
>>>>>>>>> testing of
>>>>>>>>> the
>>>>>>>>> latest security patches and trying to release at least 10 days
>>>>>>>>> before
>>>>>>>>> Christmas seemed to be almost mutually exclusive goals.
>>>>>>>>> So what do we learn from this experience?
>>>>>>>>> 1. Should we think about other planned release dates (e.g. May and
>>>>>>>>>       November - would that collide with any holiday season)?
>>>>>>>>> 2. Shouldn't we have tried to include the latest security
>>>>>>>>> patches in
>>>>>>>>>       4.10, resulting in the need for 4.10.1 at once?
>>>>>>>> I am not sure to understand this questions here.
>>>>>>> Hmm, yes, this is somehow garbled.
>>>>>>> Next try:
>>>>>>> 2. Should we have released 4.10 without those late security patches,
>>>>>>>      resulting in the need for 4.10.1 at once?
>>>>>> We were not ready to release on the 2nd December. This would have put
>>>>>> the release date too close to XSAs published date. The risk was
>>>>>> that the
>>>>>> security issues announcement would overshadow the release
>>>>>> announcement.
>>>>> Okay. So for me it seems as if a planned release early December is the
>>>>> main problem: either the release slips no more than 2 weeks or it will
>>>>> slip for more than 5 weeks.
>>>>> Having only 2 weeks of spare time is a major risk.
>>>> What I'd like to suggest is to move the target release dates to early
>>>> May and November. Or would this create a conflict with any holiday
>>>> season we care about?
>>> I think one concern was that if we release in early May, the feature
>>> freeze would be early March, which will often be right after Chinese
>>> New Year (a bit like having the feature freeze on January 5).
>>> But having the feature freeze up shortly after a major holiday is
>>> probably less bad than having the release shortly before a major
>>> holiday (as we have had this time).
>> Yu would unofficially put the feature freeze for anyone "affected" by
>> the major holidays.
>> So it might be wiser to move the feature freeze before the holidays.
>> This would help planning and avoid adding frustration around the feature
>> freeze.
> Hmm, really?
> So I should freeze one or two weeks earlier just because someone _might_
> be on vacation? So I would eventually delay a major feature from someone
> in Europe because of Chinese holidays? I don't think this is a good
> idea.

Consider what would happen if we had the feature freeze on 26 December.
Nearly everyone from Europe and the Americas *would* be on vacation;
there would be no "might" about it.

And it would cause problems interacting between regions of people on
holiday and not on holiday:
 - For people submitting code to maintainers celebrating Christmas, the
maintainer wouldn't be around to review patches submitted on Christmas.
So code submitted in accordance with the official timeline wouldn't get in.
 - For submitters who celebrate Christmas to maintainers who don't: The
submitter may not be able to re-submit patches after say, Dec 20.  If
the maintainer doesn't review their patches until the 21st or 22nd, the
patch may well miss the window even though the submitter did everything
in their power to get it in before the freeze.

The same thing is true in Asia for Chinese New Year: nearly everyone
*would* be on vacation, no "might" about it; if we want our project to
be accessible to people in Asia (and I think we do), we need to take it
into consideration.

I don't really understand Julien's argument here, or what he's
suggesting though.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.