Re: [Xen-devel] Xen release cycle revisited

[Juergen Gross <jgross@xxxxxxxx>]

On 18/12/17 21:27, Julien Grall wrote:
> Hi Juergen,
> 
> On 18/12/2017 18:32, Juergen Gross wrote:
>> On 18/12/17 17:38, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 18/12/17 16:10, 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.
>>> Chinese NY is quite important in China. Knowing that they are
>>> contributing a lot to Xen, it is not only someone but an important part
>>> of the contributors.
>>>
>>> Any major holidays affecting Europe/US is likely going to affect the
>>> release. Mostly because the a major part of the maintainers are in
>>> Europe/US today.
>>>
>>> So you would delay feature from someone in China because of European/US
>>> holidays. How this would this be fine compare to the invert?
>>
>> So I don't get why moving the freeze date _before_ the holidays as you
>> suggested would not delay that feature. I can't believe that making the
>> development phase shorter will help more features to be finished.
>>
>> Putting the freeze date at before the holidays will just hurt _all_
>> developers while for those being on vacation nothing changes regardless
>> whether the freeze is at the beginning or at the end of their holidays.
> 
> It does change a bit for developer on vacation. IHMO it is better going
> on official holidays (IIRC this is what it is in China) knowing that my
> feature was not merged because on the deadline rather than because I was
> on holidays... I don't think I am the only one who like that.
> 
> What you will end up to have is more people requesting an extension
> because the feature freeze is right at the end of their holidays. You
> will have to say no because on our policy (freeze exception). That will
> frustrate a bit more the person. Hence, why I think putting before a
> major holidays make easier.
> 
>>
>> What _is_ changing, though, is their ability to react on a potential bug
>> when the freeze date has come: with the freeze date at the start of
>> their holidays they will be able to fix the bug only after the end of
>> their holidays, so the freeze period is longer without any win for the
>> whole project.
> 
> I think George's e-mail summarize quite well what I am trying to convey.
> You have to take into account the two sides: submitter and maintainer.
> 
>>
>> What we should try to avoid in any case is a major part of the community
>> being on vacation between freeze date and release of the new version. As
>> we can't know for sure how long this phase will be we should make sure
>> to make it as long as possible, so setting the freeze date at the end of
>> a holidays season is just the right thing to do.
>>
>> I'm open for other suggestions regarding the dates, of course. So I
>> believe the first thing we should do is to write down the holidays we'd
>> like to avoid. Then we should find the two longest time spans without
>> any major holidays about 6 months apart to settle the freeze and the
>> potential release dates. The freeze dates should be as early as possible
>> allowing for the maximum time until the release dates.
>>
>> So IMO we want to avoid the following holidays seasons:
>> - Chinese new year: 1 week after Jan 22 ... Feb 17
>> - Main holidays season Europe/US: July, August
>> - Christmas: Dec 24 - Jan 1 (maybe longer?)
>> Adding e.g. Eastern would make it very hard to find a suitable date:
>> effectively mid of December until end of February are already blocked by
>> above dates. Adding Eastern would add 2 further months unless we adapt
>> each year individually (which is possible, of course).
> 
> It is probably worth for you to have a look at the Wei's RFC regarding
> 6-months releases:
> 
> https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html

I did that.

My proposal addresses the 4.10 experience. I see the following
alternatives (assuming we want to keep the two releases per year
scheme):

1. Leave everything as is
   Pro: seems to work for the June release
   Con: release date for the December release is risky

2. Move releases one month earlier, freeze dates as well (my proposal)
   Pro: more time for release at end of the year
   Con: freeze date end of February at end of Chinese New Year holidays
        in some years (2018 not applicable, as we would move that
        release by 2 weeks only, so next time this will really hit us
        will be 2026, maybe a little bit in 2021)

3. Move releases one month earlier, freeze dates before holidays
   Pro: developers won't have to let feature slip due to holiday
   Con: shorter development time for _all_ developers

4. Keep the June release like today, move the December release 2 or 4
   weeks earlier
   Pro: all Pros of 1-3
   Con: every second release will have shorter development cycle

Regarding your argument with maintainers and freeze period: technically
this is correct, but I'm not aware of many maintainers living in China,
so this is right now a minor reason for any special arrangement of the
freeze period with Chinese New Year (OTOH I'm aware this might change
at any time).

My preference right now would be (most preferred first): 4, 2, 1, 3


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel