Xen release cycle revisited

Xen release cycle revisited

[Juergen Gross]

Hi all,

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?

3. Should we let the release slip for almost a month in such a case?

4. Should we try harder to negotiate embargo dates of security issues to
   match the (targeted) release dates?

5. Should we modify the development/hardening periods?

For 4.11 we shouldn't have this problem: while targeted for releasing in
early June it wouldn't be a nightmare to let it slip into July. 4.12
however will probably face the same problem again and we should prepare
for that possibility.


Juergen

[1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html

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

Re: Xen release cycle revisited

[Julien Grall]

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.

> 
> 3. Should we let the release slip for almost a month in such a case?

The problem is XSAs can happen at any time. Let's imagine we decided to 
release in January, what if a new security was discovered during 
christmas? Are we going to slip the release again?

> 
> 4. Should we try harder to negotiate embargo dates of security issues to
>     match the (targeted) release dates?

Those 4 XSAs was first released under embargoed a couple of days before 
the targeted release dates.

The usual embargo period is 2 weeks. I think it would be difficult to 
request a shorter embargo period because downstream product need time to 
apply/test the security fixes.

> 
> 5. Should we modify the development/hardening periods?
> 
> For 4.11 we shouldn't have this problem: while targeted for releasing in
> early June it wouldn't be a nightmare to let it slip into July. 4.12
> however will probably face the same problem again and we should prepare
> for that possibility.
> 
> 
> Juergen
> 
> [1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html

Cheers,

-- 
Julien Grall

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

Re: Xen release cycle revisited

[Juergen Gross]

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?

> 
>>
>> 3. Should we let the release slip for almost a month in such a case?
> 
> The problem is XSAs can happen at any time. Let's imagine we decided to
> release in January, what if a new security was discovered during
> christmas? Are we going to slip the release again?

Go back to 2. :-)

> 
>>
>> 4. Should we try harder to negotiate embargo dates of security issues to
>>     match the (targeted) release dates?
> 
> Those 4 XSAs was first released under embargoed a couple of days before
> the targeted release dates.
> 
> The usual embargo period is 2 weeks. I think it would be difficult to
> request a shorter embargo period because downstream product need time to
> apply/test the security fixes.

Right. What about a longer embargo so that it ends well after the
release date? Last minute XSAs just before a 2-3 week period where
a release can't happen (like at Xmas) are the problem.


Juergen

> 
>>
>> 5. Should we modify the development/hardening periods?
>>
>> For 4.11 we shouldn't have this problem: while targeted for releasing in
>> early June it wouldn't be a nightmare to let it slip into July. 4.12
>> however will probably face the same problem again and we should prepare
>> for that possibility.
>>
>>
>> Juergen
>>
>> [1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html
> 
> Cheers,
> 


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

Re: Xen release cycle revisited

[Julien Grall]

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.

> 
>>
>>>
>>> 3. Should we let the release slip for almost a month in such a case?
>>
>> The problem is XSAs can happen at any time. Let's imagine we decided to
>> release in January, what if a new security was discovered during
>> christmas? Are we going to slip the release again?
> 
> Go back to 2. :-)
> 
>>
>>>
>>> 4. Should we try harder to negotiate embargo dates of security issues to
>>>      match the (targeted) release dates?
>>
>> Those 4 XSAs was first released under embargoed a couple of days before
>> the targeted release dates.
>>
>> The usual embargo period is 2 weeks. I think it would be difficult to
>> request a shorter embargo period because downstream product need time to
>> apply/test the security fixes.
> 
> Right. What about a longer embargo so that it ends well after the
> release date? Last minute XSAs just before a 2-3 week period where
> a release can't happen (like at Xmas) are the problem.

I guess that could work. The security team would have to convince the 
discoverer if he/she is happy with it.

Cheers,

-- 
Julien Grall

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

Re: Xen release cycle revisited

[Juergen Gross]

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.

> 
>>
>>>
>>>>
>>>> 3. Should we let the release slip for almost a month in such a case?
>>>
>>> The problem is XSAs can happen at any time. Let's imagine we decided to
>>> release in January, what if a new security was discovered during
>>> christmas? Are we going to slip the release again?
>>
>> Go back to 2. :-)
>>
>>>
>>>>
>>>> 4. Should we try harder to negotiate embargo dates of security
>>>> issues to
>>>>      match the (targeted) release dates?
>>>
>>> Those 4 XSAs was first released under embargoed a couple of days before
>>> the targeted release dates.
>>>
>>> The usual embargo period is 2 weeks. I think it would be difficult to
>>> request a shorter embargo period because downstream product need time to
>>> apply/test the security fixes.
>>
>> Right. What about a longer embargo so that it ends well after the
>> release date? Last minute XSAs just before a 2-3 week period where
>> a release can't happen (like at Xmas) are the problem.
> 
> I guess that could work. The security team would have to convince the
> discoverer if he/she is happy with it.

Sure, like Ian pointed out in another thread.


Juergen

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

Re: Xen release cycle revisited

[Jan Beulich]

>>> On 14.12.17 at 12:38, <jgross@suse.com> wrote:
> 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 don't make point releases just for security issues on other
branches - why would we do so right after a .0 release? We
really have to decide whether delaying is worthwhile, or whether
releasing on time with known (security) flaws is the better option.
I know which of the two I would always choose (and hence I'm
happy we've waited with 4.10).

Jan


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

Re: Xen release cycle revisited

[Jan Beulich]

>>> On 14.12.17 at 08:56, <jgross@suse.com> wrote:
> 4. Should we try harder to negotiate embargo dates of security issues to
>    match the (targeted) release dates?

Personally I don't think embargo dates should be made match
release dates; if anything, the other way around. Holding back
security issues is just bad (and I'm saying that being well aware
that we hold ones back longer than is actually necessary, for
reasons which I don't want to discuss here).

Jan


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

Re: Xen release cycle revisited

[Juergen Gross]

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?

In order not to have a very short release cycle for 4.11 I'd do the
shift in two steps (so 4.11 target release date mid of May, 4.12 early
November).

What do you think?


Juergen

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

Re: Xen release cycle revisited

[George Dunlap]

On Fri, Dec 15, 2017 at 2:54 PM, Juergen Gross <jgross@suse.com> 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).

> In order not to have a very short release cycle for 4.11 I'd do the
> shift in two steps (so 4.11 target release date mid of May, 4.12 early
> November).

 That would work for  me.

 -George

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

Re: Xen release cycle revisited

[George Dunlap]

On Thu, Dec 14, 2017 at 2:11 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.12.17 at 08:56, <jgross@suse.com> wrote:
>> 4. Should we try harder to negotiate embargo dates of security issues to
>>    match the (targeted) release dates?
>
> Personally I don't think embargo dates should be made match
> release dates; if anything, the other way around. Holding back
> security issues is just bad (and I'm saying that being well aware
> that we hold ones back longer than is actually necessary, for
> reasons which I don't want to discuss here).

We had a discussion at our team meeting last Thursday, and I think
fundamentally it takes at least week of testing to be reasonably
confident that we don't have unknown "howlers" (i.e., embarrassing
bugs in basic functionality).

Which means we have three basic options:

1. Release with no known bugs, and confident that there are no
"howlers".  This means we have to be willing to slip the release by
one week, every time a new bug is discovered, *for as long as it
takes*.

2. Release at a specific date, confident that there are no "howlers".
This means shipping with known bugs (i.e., any bugs for which patches
have been submitted 1 week before the target date aren't included).

3. Releasing with no known bugs, at a specific date.  This means
taking the risk that there is basic functionality that is completely
broken, because we didn't test it properly.

It would be nice if we didn't have to choose between these three
things (specific date, all known bugs fixed, confident of no
'howlers'); but that's not the universe we live in, and attempting to
deny that fact led us this time to de facto choose #3 (i.e., we
decided we were going to ship on 12 December, with all the known bugs
fixed, but not give enough time for testing to see if we had
introduced any 'howlers').  (NB that I'm not blaming anybody in
particular here -- Julien discussed his plan and it was agree upon by
several people including myself.)

This is a slight simplification.  For instance, we can always start
with #1 and switch to #2 or #3 at any time: i.e., allow the release
date to slip a few times, and then fix the date and release either
with known bugs or release insufficiently tested.  (That's essentially
what we did this time.)  We could also decide to ship with "minor"
bugs, but slip the release indefinitely for "major" bugs.

I don't have a strong preference between #1 and #2, but I think we
definitely want to avoid #3.  But to do that we (or perhaps the
Release Manager) needs to decide which option to choose (slip
indefinitely or ship with known bugs) and stick with it.

 -George

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

Re: Xen release cycle revisited

[Julien Grall]

Hi George,

On 18/12/17 14:56, George Dunlap wrote:
> On Fri, Dec 15, 2017 at 2:54 PM, Juergen Gross <jgross@suse.com> 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.

Cheers,

-- 
Julien Grall

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

Re: Xen release cycle revisited

[Juergen Gross]

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@suse.com> 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.

We don't want the release to be delayed because of holidays, as we have
to make sure bugs are possibly fixed in a timely manner. Holidays before
freeze date will affect some features only. And as the freeze date is
known in advance anyone developing new features knows when holidays
might affect readiness of the feature.


Juergen

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

Re: Xen release cycle revisited

[Julien Grall]

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@suse.com> 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?

Cheers,

-- 
Julien Grall

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

Re: Xen release cycle revisited

[George Dunlap]

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@suse.com> 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.

 -George

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

Re: Xen release cycle revisited

[Juergen Gross]

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@suse.com> 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.

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.

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).


Juergen

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

Re: Xen release cycle revisited

[Julien Grall]

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@suse.com> 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

Cheers,

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

Re: Xen release cycle revisited

[Juergen Gross]

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@suse.com>
>>>>>> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen release cycle revisited

[Jan Beulich]

>>> On 19.12.17 at 07:58, <jgross@suse.com> wrote:
> 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

5. Go to a yearly release cycle, with June as expected release date.
At the risk of (still) being the only one to dislike the 6-month cycle,
I have to say that there, at the moment, being 4 actively maintained
stable branches and 6 security maintained ones is - just like I did
anticipate back when we discussed the shortening of the cycle - a
significant burden. And we haven't even reached the point yet
where all security maintained branches are from the 6-month cycle.

Jan


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

Re: Xen release cycle revisited

[Steven Haigh]

[-- Attachment #1.1: Type: text/plain, Size: 2499 bytes --]

On Tuesday, 19 December 2017 7:47:14 PM AEDT Jan Beulich wrote:
> >>> On 19.12.17 at 07:58, <jgross@suse.com> wrote:
> > 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
> 
> 5. Go to a yearly release cycle, with June as expected release date.
> At the risk of (still) being the only one to dislike the 6-month cycle,
> I have to say that there, at the moment, being 4 actively maintained
> stable branches and 6 security maintained ones is - just like I did
> anticipate back when we discussed the shortening of the cycle - a
> significant burden. And we haven't even reached the point yet
> where all security maintained branches are from the 6-month cycle.

I've gotta agree here - I've already been skipping releases to keep up. 4.8 
was a complete non-starter for me, and 4.10 might be the same. Its exhausting.

I'm not sure there are really enough under-the-hood changes to justify a 6 
month rapid release cycle.

It adds extra load on the security team, packagers, distro builders etc etc 
which could probably be avoided with a sane release cycle.

I would think one release per year + point releases / roll ups with all XSAs 
and backported fixes every quarter would be fantastic - as well as a 'master' 
that people can build off git at will...

-- 
Steven Haigh

📧 netwiz@crc.id.au       💻 http://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen release cycle revisited

[George Dunlap]

On 12/19/2017 10:42 AM, Steven Haigh wrote:
> On Tuesday, 19 December 2017 7:47:14 PM AEDT Jan Beulich wrote:
>>>>> On 19.12.17 at 07:58, <jgross@suse.com> wrote:
>>> 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
>>
>> 5. Go to a yearly release cycle, with June as expected release date.
>> At the risk of (still) being the only one to dislike the 6-month cycle,
>> I have to say that there, at the moment, being 4 actively maintained
>> stable branches and 6 security maintained ones is - just like I did
>> anticipate back when we discussed the shortening of the cycle - a
>> significant burden. And we haven't even reached the point yet
>> where all security maintained branches are from the 6-month cycle.
> 
> I've gotta agree here - I've already been skipping releases to keep up. 4.8 
> was a complete non-starter for me, and 4.10 might be the same. Its exhausting.

FWIW the CentOS Virt SIG had already decided to only consider updating
every other release, back when the release cadence was 9 months (leaving
a year and a half between upgrades).

But of course, that's in part  because CentOS is meant to be "stodgy and
reliable".  Fedora and Ubuntu, for instance, have 6-month release
cycles.  It looks like Ubuntu 17.10 has Xen 4.9 in it; and there's no
reason to think Ubuntu 18.04 LTS won't have 4.10 in it.

Steven, when I glanced at your site it looked like you're actively
supporting all versions of Xen you've ever released -- is that right?
If so it's a lot more work than I think anyone else is doing. :-)

 -George

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

Re: Xen release cycle revisited

[Steven Haigh]

[-- Attachment #1.1: Type: text/plain, Size: 4003 bytes --]

On Tuesday, 19 December 2017 10:44:04 PM AEDT George Dunlap wrote:
> On 12/19/2017 10:42 AM, Steven Haigh wrote:
> > On Tuesday, 19 December 2017 7:47:14 PM AEDT Jan Beulich wrote:
> >>>>> On 19.12.17 at 07:58, <jgross@suse.com> wrote:
> >>> 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
> >> 
> >> 5. Go to a yearly release cycle, with June as expected release date.
> >> At the risk of (still) being the only one to dislike the 6-month cycle,
> >> I have to say that there, at the moment, being 4 actively maintained
> >> stable branches and 6 security maintained ones is - just like I did
> >> anticipate back when we discussed the shortening of the cycle - a
> >> significant burden. And we haven't even reached the point yet
> >> where all security maintained branches are from the 6-month cycle.
> > 
> > I've gotta agree here - I've already been skipping releases to keep up.
> > 4.8
> > was a complete non-starter for me, and 4.10 might be the same. Its
> > exhausting.
> FWIW the CentOS Virt SIG had already decided to only consider updating
> every other release, back when the release cadence was 9 months (leaving
> a year and a half between upgrades).

Understandable.
 
> But of course, that's in part  because CentOS is meant to be "stodgy and
> reliable".  Fedora and Ubuntu, for instance, have 6-month release
> cycles.  It looks like Ubuntu 17.10 has Xen 4.9 in it; and there's no
> reason to think Ubuntu 18.04 LTS won't have 4.10 in it.

Agreed - but things like Fedora evolve pretty rapidly. I'm not sure Xen is in 
the same rapid development model - so I don't think we should follow suit in 
this. It would be more than reasonable to have, say, Xen 4.10.0 in one version 
of Fedora - and 4.10.2 in the next...

> Steven, when I glanced at your site it looked like you're actively
> supporting all versions of Xen you've ever released -- is that right?
> If so it's a lot more work than I think anyone else is doing. :-)

Correct. The only versions I don't support are EOL'ed versions and 4.8 - which 
I skipped due to workload.

This means the current build list is 4.5, 4.6, 4.7, 4.9 for both EL6 and EL7.

4.2 and 4.4 got EOL'ed a while back and I don't make them available anymore.

If I didn't miss a 4.8 and already had 4.10 out the door, then I'd be 
publishing 4.5, 4.6, 4.7, 4.8, 4.9 and 4.10. I'm not sure if that's feasible 
for anyone - let alone how it'd be managed effectively by the security team!

For me personally, December release dates for builds is horrible - so its 
likely just about any December release would be on the ignore list - hence I 
feel a single yearly release in July (+/- up to 2 months) would be fine as a 
target.

-- 
Steven Haigh

📧 netwiz@crc.id.au       💻 http://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen release cycle revisited

[Lars Kurth]

Hi Juergen:

thank you for raising this. As far as I can tell, the switch to the 6-monthly release model has had some consequences, some of which were predicted, others were not. So, I think we should probably review the decision. 

Key concerns raised:
• Too much work in actively maintaining 4 branches (6 security branches)
• Impact on users (too many releases)
• I think we are definitely incurring higher overheads than with longer cycles
• It is not clear to me whether one of the key benefits – aka vendors getting patches into tree more easily – has in fact materialized
• Better release predictability has materialized

Maybe the right approach would be to kick off some kind of survey to gather input from different stake-holders and maybe plan 4.11 for June. If there is a consensus for a change to say a year cadence, we probably wouldn’t execute this until 4.12 anyway. 

Maybe make some minor adjustments for the 4.11 cycle based on this thread, if it makes sense to do so.

Regards
Lars

On 14/12/2017, 07:56, "Juergen Gross" <jgross@suse.com> wrote:

    Hi all,
    
    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?
    
    3. Should we let the release slip for almost a month in such a case?
    
    4. Should we try harder to negotiate embargo dates of security issues to
       match the (targeted) release dates?
    
    5. Should we modify the development/hardening periods?
    
    For 4.11 we shouldn't have this problem: while targeted for releasing in
    early June it wouldn't be a nightmare to let it slip into July. 4.12
    however will probably face the same problem again and we should prepare
    for that possibility.
    
    
    Juergen
    
    [1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html
    

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

Re: Xen release cycle revisited

[Juergen Gross]

On 02/01/18 13:54, Lars Kurth wrote:
> Hi Juergen:
> 
> thank you for raising this. As far as I can tell, the switch to the 6-monthly release model has had some consequences, some of which were predicted, others were not. So, I think we should probably review the decision. 
> 
> Key concerns raised:
> • Too much work in actively maintaining 4 branches (6 security branches)
> • Impact on users (too many releases)
> • I think we are definitely incurring higher overheads than with longer cycles
> • It is not clear to me whether one of the key benefits – aka vendors getting patches into tree more easily – has in fact materialized
> • Better release predictability has materialized
> 
> Maybe the right approach would be to kick off some kind of survey to gather input from different stake-holders and maybe plan 4.11 for June. If there is a consensus for a change to say a year cadence, we probably wouldn’t execute this until 4.12 anyway.

Okay, in case nobody objects I'll send out the 4.11 plan on Friday.
I'm planning for a timeline like:

* Last posting date: March 16th, 2018
* Hard code freeze: March 30th, 2018
* Release: June 1st, 2018


Juergen

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

Re: Xen release cycle revisited

[Steven Haigh]

[-- Attachment #1.1: Type: text/plain, Size: 1759 bytes --]

On Tuesday, 2 January 2018 11:54:43 PM AEDT Lars Kurth wrote:
> Hi Juergen:
> 
> thank you for raising this. As far as I can tell, the switch to the
> 6-monthly release model has had some consequences, some of which were
> predicted, others were not. So, I think we should probably review the
> decision. 
 
> Key concerns raised:
> • Too much work in actively maintaining 4 branches (6 security branches)
> • Impact on users (too many releases)
> • I think we are definitely incurring higher overheads than with longer
> cycles
 • It is not clear to me whether one of the key benefits – aka
> vendors getting patches into tree more easily – has in fact materialized •
> Better release predictability has materialized
> 
> Maybe the right approach would be to kick off some kind of survey to gather
> input from different stake-holders and maybe plan 4.11 for June. If there
> is a consensus for a change to say a year cadence, we probably wouldn’t
> execute this until 4.12 anyway. 

I would like to propose for consideration:

* 12 months between major releases (x.y)
* 3 or 4 months between point releases (x.y.z)

This way, we roll up all XSAs etc into a x.y.z release on a regular basis - 
which I believe would make the security teams job easier (let me know if I'm 
wrong with this?).

Then aim to release x.y+1 (or maybe x+1?) in, say, June each year.

I'm not sure if there has been a set time frame as a goal for x.y.z releases - 
from my not so close observations, they seem to be somewhat adhoc.

As always though - more than happy to get feedback / comments on the above.

-- 
Steven Haigh

📧 netwiz@crc.id.au       💻 http://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen release cycle revisited

[Jan Beulich]

>>> On 02.01.18 at 16:07, <netwiz@crc.id.au> wrote:
> I'm not sure if there has been a set time frame as a goal for x.y.z releases - 
> from my not so close observations, they seem to be somewhat adhoc.

We're trying to get them out on a 4 month cadence, but there's
almost always a reason that causes them to be delayed.

Jan


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