* Xen release cycle revisited @ 2017-12-14 7:56 Juergen Gross 2017-12-14 11:28 ` Julien Grall ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Juergen Gross @ 2017-12-14 7:56 UTC (permalink / raw) To: xen-devel; +Cc: Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 7:56 Xen release cycle revisited Juergen Gross @ 2017-12-14 11:28 ` Julien Grall 2017-12-14 11:38 ` Juergen Gross 2017-12-14 14:11 ` Jan Beulich 2018-01-02 12:54 ` Lars Kurth 2 siblings, 1 reply; 25+ messages in thread From: Julien Grall @ 2017-12-14 11:28 UTC (permalink / raw) To: Juergen Gross, xen-devel; +Cc: Lars Kurth, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 11:28 ` Julien Grall @ 2017-12-14 11:38 ` Juergen Gross 2017-12-14 12:43 ` Julien Grall 2017-12-14 14:07 ` Jan Beulich 0 siblings, 2 replies; 25+ messages in thread From: Juergen Gross @ 2017-12-14 11:38 UTC (permalink / raw) To: Julien Grall, xen-devel; +Cc: Lars Kurth, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 11:38 ` Juergen Gross @ 2017-12-14 12:43 ` Julien Grall 2017-12-14 13:13 ` Juergen Gross 2017-12-14 14:07 ` Jan Beulich 1 sibling, 1 reply; 25+ messages in thread From: Julien Grall @ 2017-12-14 12:43 UTC (permalink / raw) To: Juergen Gross, xen-devel; +Cc: Lars Kurth, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 12:43 ` Julien Grall @ 2017-12-14 13:13 ` Juergen Gross 2017-12-15 14:54 ` Juergen Gross 0 siblings, 1 reply; 25+ messages in thread From: Juergen Gross @ 2017-12-14 13:13 UTC (permalink / raw) To: Julien Grall, xen-devel; +Cc: Lars Kurth, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 13:13 ` Juergen Gross @ 2017-12-15 14:54 ` Juergen Gross 2017-12-18 14:56 ` George Dunlap 0 siblings, 1 reply; 25+ messages in thread From: Juergen Gross @ 2017-12-15 14:54 UTC (permalink / raw) To: Julien Grall, xen-devel; +Cc: Lars Kurth, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-15 14:54 ` Juergen Gross @ 2017-12-18 14:56 ` George Dunlap 2017-12-18 15:57 ` Julien Grall 0 siblings, 1 reply; 25+ messages in thread From: George Dunlap @ 2017-12-18 14:56 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Julien Grall, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 14:56 ` George Dunlap @ 2017-12-18 15:57 ` Julien Grall 2017-12-18 16:10 ` Juergen Gross 0 siblings, 1 reply; 25+ messages in thread From: Julien Grall @ 2017-12-18 15:57 UTC (permalink / raw) To: George Dunlap, Juergen Gross; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 15:57 ` Julien Grall @ 2017-12-18 16:10 ` Juergen Gross 2017-12-18 16:38 ` Julien Grall 2017-12-18 16:53 ` George Dunlap 0 siblings, 2 replies; 25+ messages in thread From: Juergen Gross @ 2017-12-18 16:10 UTC (permalink / raw) To: Julien Grall, George Dunlap; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 16:10 ` Juergen Gross @ 2017-12-18 16:38 ` Julien Grall 2017-12-18 18:32 ` Juergen Gross 2017-12-18 16:53 ` George Dunlap 1 sibling, 1 reply; 25+ messages in thread From: Julien Grall @ 2017-12-18 16:38 UTC (permalink / raw) To: Juergen Gross, George Dunlap; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 16:38 ` Julien Grall @ 2017-12-18 18:32 ` Juergen Gross 2017-12-18 20:27 ` Julien Grall 0 siblings, 1 reply; 25+ messages in thread From: Juergen Gross @ 2017-12-18 18:32 UTC (permalink / raw) To: Julien Grall, George Dunlap; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 18:32 ` Juergen Gross @ 2017-12-18 20:27 ` Julien Grall 2017-12-19 6:58 ` Juergen Gross 0 siblings, 1 reply; 25+ messages in thread From: Julien Grall @ 2017-12-18 20:27 UTC (permalink / raw) To: Juergen Gross, George Dunlap; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 20:27 ` Julien Grall @ 2017-12-19 6:58 ` Juergen Gross 2017-12-19 8:47 ` Jan Beulich 0 siblings, 1 reply; 25+ messages in thread From: Juergen Gross @ 2017-12-19 6:58 UTC (permalink / raw) To: Julien Grall, George Dunlap; +Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-19 6:58 ` Juergen Gross @ 2017-12-19 8:47 ` Jan Beulich 2017-12-19 10:42 ` Steven Haigh 0 siblings, 1 reply; 25+ messages in thread From: Jan Beulich @ 2017-12-19 8:47 UTC (permalink / raw) To: Julien Grall, Juergen Gross, George Dunlap Cc: Lars Kurth, committers, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-19 8:47 ` Jan Beulich @ 2017-12-19 10:42 ` Steven Haigh 2017-12-19 11:44 ` George Dunlap 0 siblings, 1 reply; 25+ messages in thread From: Steven Haigh @ 2017-12-19 10:42 UTC (permalink / raw) To: xen-devel Cc: Juergen Gross, Lars Kurth, George Dunlap, Julien Grall, committers, Jan Beulich, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-19 10:42 ` Steven Haigh @ 2017-12-19 11:44 ` George Dunlap 2017-12-19 12:25 ` Steven Haigh 0 siblings, 1 reply; 25+ messages in thread From: George Dunlap @ 2017-12-19 11:44 UTC (permalink / raw) To: Steven Haigh, xen-devel Cc: Juergen Gross, Lars Kurth, George Dunlap, Julien Grall, committers, Jan Beulich, xen-devel 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-19 11:44 ` George Dunlap @ 2017-12-19 12:25 ` Steven Haigh 0 siblings, 0 replies; 25+ messages in thread From: Steven Haigh @ 2017-12-19 12:25 UTC (permalink / raw) To: George Dunlap Cc: Juergen Gross, Lars Kurth, George Dunlap, Julien Grall, xen-devel, committers, Jan Beulich, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-18 16:10 ` Juergen Gross 2017-12-18 16:38 ` Julien Grall @ 2017-12-18 16:53 ` George Dunlap 1 sibling, 0 replies; 25+ messages in thread From: George Dunlap @ 2017-12-18 16:53 UTC (permalink / raw) To: Juergen Gross, Julien Grall, George Dunlap Cc: xen-devel, committers, Lars Kurth 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 11:38 ` Juergen Gross 2017-12-14 12:43 ` Julien Grall @ 2017-12-14 14:07 ` Jan Beulich 1 sibling, 0 replies; 25+ messages in thread From: Jan Beulich @ 2017-12-14 14:07 UTC (permalink / raw) To: Juergen Gross; +Cc: Lars Kurth, Julien Grall, committers, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 7:56 Xen release cycle revisited Juergen Gross 2017-12-14 11:28 ` Julien Grall @ 2017-12-14 14:11 ` Jan Beulich 2017-12-18 15:48 ` George Dunlap 2018-01-02 12:54 ` Lars Kurth 2 siblings, 1 reply; 25+ messages in thread From: Jan Beulich @ 2017-12-14 14:11 UTC (permalink / raw) To: Juergen Gross; +Cc: Lars Kurth, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 14:11 ` Jan Beulich @ 2017-12-18 15:48 ` George Dunlap 0 siblings, 0 replies; 25+ messages in thread From: George Dunlap @ 2017-12-18 15:48 UTC (permalink / raw) To: Jan Beulich; +Cc: Juergen Gross, Lars Kurth, xen-devel 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2017-12-14 7:56 Xen release cycle revisited Juergen Gross 2017-12-14 11:28 ` Julien Grall 2017-12-14 14:11 ` Jan Beulich @ 2018-01-02 12:54 ` Lars Kurth 2018-01-02 13:10 ` Juergen Gross 2018-01-02 15:07 ` Steven Haigh 2 siblings, 2 replies; 25+ messages in thread From: Lars Kurth @ 2018-01-02 12:54 UTC (permalink / raw) To: Juergen Gross, xen-devel, Steven Haigh, Jan Beulich, Julien Grall 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2018-01-02 12:54 ` Lars Kurth @ 2018-01-02 13:10 ` Juergen Gross 2018-01-02 15:07 ` Steven Haigh 1 sibling, 0 replies; 25+ messages in thread From: Juergen Gross @ 2018-01-02 13:10 UTC (permalink / raw) To: Lars Kurth, xen-devel, Steven Haigh, Jan Beulich, Julien Grall, George Dunlap, committers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2018-01-02 12:54 ` Lars Kurth 2018-01-02 13:10 ` Juergen Gross @ 2018-01-02 15:07 ` Steven Haigh 2018-01-02 16:22 ` Jan Beulich 1 sibling, 1 reply; 25+ messages in thread From: Steven Haigh @ 2018-01-02 15:07 UTC (permalink / raw) To: Lars Kurth Cc: Juergen Gross, George Dunlap, Julien Grall, committers, Jan Beulich, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Xen release cycle revisited 2018-01-02 15:07 ` Steven Haigh @ 2018-01-02 16:22 ` Jan Beulich 0 siblings, 0 replies; 25+ messages in thread From: Jan Beulich @ 2018-01-02 16:22 UTC (permalink / raw) To: Steven Haigh Cc: Juergen Gross, Lars Kurth, George Dunlap, Julien Grall, committers, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-01-02 16:22 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-14 7:56 Xen release cycle revisited Juergen Gross 2017-12-14 11:28 ` Julien Grall 2017-12-14 11:38 ` Juergen Gross 2017-12-14 12:43 ` Julien Grall 2017-12-14 13:13 ` Juergen Gross 2017-12-15 14:54 ` Juergen Gross 2017-12-18 14:56 ` George Dunlap 2017-12-18 15:57 ` Julien Grall 2017-12-18 16:10 ` Juergen Gross 2017-12-18 16:38 ` Julien Grall 2017-12-18 18:32 ` Juergen Gross 2017-12-18 20:27 ` Julien Grall 2017-12-19 6:58 ` Juergen Gross 2017-12-19 8:47 ` Jan Beulich 2017-12-19 10:42 ` Steven Haigh 2017-12-19 11:44 ` George Dunlap 2017-12-19 12:25 ` Steven Haigh 2017-12-18 16:53 ` George Dunlap 2017-12-14 14:07 ` Jan Beulich 2017-12-14 14:11 ` Jan Beulich 2017-12-18 15:48 ` George Dunlap 2018-01-02 12:54 ` Lars Kurth 2018-01-02 13:10 ` Juergen Gross 2018-01-02 15:07 ` Steven Haigh 2018-01-02 16:22 ` Jan Beulich
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.