Re: [Xen-devel] RFC: Survey on release cycle
On 12/10/15 18:32, Wei Liu wrote: > Hi all > > > > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). With my XenServer hat on, the precise release doesn't matter too much. For a XenServer release, we will choose something (generally lastest stable-X.Y) and freeze on it, with only targeted bug/security fixes being backported later on. However, with my upstream hat on, we do have a problem, and changing the release cadence seems to be a plausible experiment to investigate fixing it. > > # 6 months release cycle + current stable release scheme > # 6 months release cycle + LTS scheme +1 to either of these. > > > # 9 months release cycle + current stable release scheme -1 > > Don't change anything. -1 ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
Wei Liu writes ("[Xen-devel] RFC: Survey on release cycle"): > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). > > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. +2 > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. +1 > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). > > # 9 months release cycle + current stable release scheme -2 Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
Ian Campbell writes ("Re: [Xen-devel] RFC: Survey on release cycle"): > On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > > The same stable release scheme applies (18 months full support + 18 > > months security fixes). Encourage more people to step up to share the > > maintenance burden if necessary. Automate part of the workflow to > > maintain stable releases. Write down guideline for maintainers. > > I think this "current stable release scheme" and "18 months full support", > implies an increase in the number of supported stable releases at any given > time. > > I'd therefore like to also propose: > > # 6 months release cycle + extended security support This would also be acceptable to me (+1 in Wei's notation). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Thu, Oct 15, Ian Campbell wrote: > On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > > > # 6 months release cycle + current stable release scheme > # 6 months release cycle + extended security support > > +1 to either of these, but +2 for picking one of them. +1, as Ian said. > (not really sure how to express that in a vote, sorry). > > > # 6 months release cycle + LTS scheme 0 > > # 9 months release cycle + current stable release scheme 0 Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > # 6 months release cycle + current stable release scheme # 6 months release cycle + extended security support +1 to either of these, but +2 for picking one of them. (not really sure how to express that in a vote, sorry). > # 6 months release cycle + LTS scheme +1 > # 9 months release cycle + current stable release scheme -1 Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
>>> On 12.10.15 at 19:32,wrote: > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. -1 (with a tendency towards 0 for the base proposal, i.e. willing to give it a try, but a tendency towards -2 for the sharing of the maintenance burden, as I don't expect much good to come from mixed maintainership of stable branches) > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. > > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). -1 (with a tendency towards -2, foreseeing non-LTS branches to become "bad children") > # 9 months release cycle + current stable release scheme > > Don't change anything. +1 > # 6 months release cycle + extended security support > > The number of active stable branches remains constant (I think this is > currently 2, implying a reducing from 18 months to 12 months) but the > security support period is extended, such that the final cut off is the > same 36 months (18+18 in the current scheme). So this becomes 12 months of > full support + 24 months of security support. 0 (with a tendency towards -1 when taking on my SUSE hat, as a reduction from 18 to 12 months of ordinary support means an increased amount of patches the various distro versions will have to carry on top of the last stable release from the respective branch) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On 10/12/2015 07:32 PM, Wei Liu wrote: Please express your preference with -2 (strongly argue against), -1 (not happy but not against), +1 (happy but won't argue for) and +2 (happy and argue for). # 6 months release cycle + current stable release scheme 0 # 6 months release cycle + LTS scheme -1 # 9 months release cycle + current stable release scheme +1 Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Wed, 2015-10-14 at 14:08 +0100, Wei Liu wrote: > On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote: > > Aside: I'm a bit confused regarding whether our "stable release scheme" is > > defined in terms of number of concurrently supported releases or in terms > > of an absolute time. > > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely > > says it is concurrent release based, but your proposal above suggests > > otherwise. Is the wiki wrong? > > > > Sorry about the confusion. I picked the time-based interpretation > because that's why I slightly preferred (again, note that all details > are merely my preferences). There is room for discussion of course. > Whether the stable releases based on absolute time or number of > concurrent releases, I won't argue for one over another. My confusion wasn't down to arguing for/against one or the other, just that the options presented did not make it clear which one they were using, which meant their use of the word "current" was potentially confusing. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > Hi all > > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). > > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. > +1 I especially like the 6 months cadence with fixed dates. Keeping the current stable release scheme could be a good thing, e.g., to avoid introducing too many changes at the same time (although, I personally think we could well give the LTS model a try, as said below). > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. > > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). > +2 I really like the 6 months cadence with fixed dates, and, although I don't have much experience with them, I like the LTS idea, enough to think that we should give it a try, at least. > # 9 months release cycle + current stable release scheme > -2 As said above, I think we should go (try) 6 Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Mon, 12 Oct 2015, Wei Liu wrote: > Hi all > > We've had two separate discussions about release cycles, one for > normal release [0], the other for changes in stable release > maintenance and possible long term supported releases [1]. There were > overwhelming support for having a shorter release cycle from > xen-unstable but we couldn't reach consensus on how to manage stable > releases. > > The details on the current 9 months release cycle and proposed 6 > months release cycle can be found in [0], while the current scheme for > stable releases can be found in [2]. A plethora of arguments can be > found in both [0] and [1], but in the end most if not all of them boil > down to empirical arguments / expectations or just merely different > opinions on the same fact so there wasn't really concrete outcome of > that two threads. > > With the release of 4.6, it's important that we have agreement so that > we can get on with planning next release. > > There are several general options on how to proceed that I summarise > from previous discussions. Note that because there are too many moving > parts I pick some of my preferences as a starting point for the > discussion. I also omit the combination of 9 months release cycle + > LTS scheme because it doesn't look attractive in the first place. > > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). > > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. +1 I think it would be a bit too much work for us, but we could probably cope. However it is still better than what we have now. > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. > > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). +2 LTSes solve the problem of the load on stable trees maintainers. > # 9 months release cycle + current stable release scheme > > Don't change anything. -2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > [...] > There are several general options on how to proceed that I summarise > from previous discussions. Note that because there are too many moving > parts I pick some of my preferences as a starting point for the > discussion. I take it suggesting (and voting upon) other options is also acceptable? Assuming so then: > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. I think this "current stable release scheme" and "18 months full support", implies an increase in the number of supported stable releases at any given time. I'd therefore like to also propose: # 6 months release cycle + extended security support The number of active stable branches remains constant (I think this is currently 2, implying a reducing from 18 months to 12 months) but the security support period is extended, such that the final cut off is the same 36 months (18+18 in the current scheme). So this becomes 12 months of full support + 24 months of security support. Aside: I'm a bit confused regarding whether our "stable release scheme" is defined in terms of number of concurrently supported releases or in terms of an absolute time. http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely says it is concurrent release based, but your proposal above suggests otherwise. Is the wiki wrong? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Wed, 2015-10-14 at 06:30 -0600, Jan Beulich wrote: > > > > On 14.10.15 at 14:21,wrote: > > Aside: I'm a bit confused regarding whether our "stable release scheme" > > is > > defined in terms of number of concurrently supported releases or in > > terms > > of an absolute time. > > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases defini > > tely > > says it is concurrent release based, but your proposal above suggests > > otherwise. Is the wiki wrong? > > I think the distinction wasn't relevant with the (intended) 9 month > cycle. That's true, it also wouldn't really be relevant with any given new cycle. But it does make talking about the new schemes confusing when they are described in terms of the current scheme implicitly assuming one way or the other. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
>>> On 14.10.15 at 14:21,wrote: > Aside: I'm a bit confused regarding whether our "stable release scheme" is > defined in terms of number of concurrently supported releases or in terms > of an absolute time. > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely > says it is concurrent release based, but your proposal above suggests > otherwise. Is the wiki wrong? I think the distinction wasn't relevant with the (intended) 9 month cycle. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote: > On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > > > [...] > > There are several general options on how to proceed that I summarise > > from previous discussions. Note that because there are too many moving > > parts I pick some of my preferences as a starting point for the > > discussion. > > I take it suggesting (and voting upon) other options is also acceptable? > Yes, of course. > Assuming so then: > > > # 6 months release cycle + current stable release scheme > > > > The same stable release scheme applies (18 months full support + 18 > > months security fixes). Encourage more people to step up to share the > > maintenance burden if necessary. Automate part of the workflow to > > maintain stable releases. Write down guideline for maintainers. > > I think this "current stable release scheme" and "18 months full support", > implies an increase in the number of supported stable releases at any given > time. > Yes, it is the case. > I'd therefore like to also propose: > > # 6 months release cycle + extended security support > > The number of active stable branches remains constant (I think this is > currently 2, implying a reducing from 18 months to 12 months) but the > security support period is extended, such that the final cut off is the > same 36 months (18+18 in the current scheme). So this becomes 12 months of > full support + 24 months of security support. > This is reasonable suggestions. I'm not quite sure about the number of full support backports vs security backports though, so the actual impact is not very clear to me. But I think it is safe to say with this scheme the work is less. > Aside: I'm a bit confused regarding whether our "stable release scheme" is > defined in terms of number of concurrently supported releases or in terms > of an absolute time. > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely > says it is concurrent release based, but your proposal above suggests > otherwise. Is the wiki wrong? > Sorry about the confusion. I picked the time-based interpretation because that's why I slightly preferred (again, note that all details are merely my preferences). There is room for discussion of course. Whether the stable releases based on absolute time or number of concurrent releases, I won't argue for one over another. I think it would be better if Jan or Ian J express their preference since they have been doing this for a long time and have better ideas of what works best, and if we need more helping hand in stable release maintenance. It's safe to say people expressed opinions so far care more about 6 months release cycle and are willing to comprise on how we manage stable releases (or LTSes). Wei. > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel