Re: [DISCUSS] LTS releases?
On Jul 2, 2015, at 4:58 PM, Remi Bergsma r...@remi.nl wrote: Bug fixing in older releases is actually a lot of work. For security related issues we could maybe do it. Personally, I prefer to have a fast release cycle and smooth (tested) upgrade paths over 2-year LTS release cycle. It's more agile. As a bonus, people get the new features. The more people do upgrades that work (tm) the more confident they are. I'd really want to show that upgrades work so well that we need no LTS. But there might be other reasons people have where LTS would help. Please share! Regards, Remi I think we got in a situation with 4.4 that called for us to keep maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release. Now that we have 4.4 and 4.5.2 etc, I don't think we will have the cycles to maintain that many release branches. The big issue is upgrade path, IMHO our LTS strategy is to have master as a release branch itself, adopt good practice to merge to master, have great upgrades and no regressions. Ultimately we should divert our efforts to master. So I am +1 with Remi on this. On 02 Jul 2015, at 16:25, Rene Moser m...@renemoser.net wrote: Maybe a little bit off topic to the new release process, therefor a new thread... speaking about releases. I just thought about supporting LTS releases. This would mean someone or we make a commitment to add bug fixes (only) for a specified time. e.g. 2 years for a release or until the next LTS release? Would this something anyone would be interested in? Yours René
Re: [DISCUSS] LTS releases?
On Jul 3, 2015, at 11:13 AM, Rene Moser m...@renemoser.net wrote: Sebastien, So wouldn't it be nice to make clear which release is still supported and which release is not? On 03.07.2015 09:20, sebgoa wrote: I think we got in a situation with 4.4 that called for us to keep maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release. Your are saying 4.3 is a good release, shouldn't it be maintained a bit longer? So currently we have: main 4.5.x stable: 4.4.x legacy: 4.3.x deprecated: 4.2.0 When 4.6 is released, what should a release be dropped? 4.4.x? main: 4.6.0 stable: 4.5.x legacy: 4.3.x What is your plan about this? What is *our* plan :) We used to only maintain the last two major releases. We diverged from that model when 4.5.0 came out and that we still wanted to maintain 4.3 because 4.3 was working so well for people. My personal preference would be to get into a rolling release model, where we maintain only the last major release. This is why making master stable and the base for all our releases is so important. Users should get into a model where they continuously upgrade/deploy and don't get stuck on a unmaintained branch with forks that prevents upgrade. When users face an issue, we patch and release, then they upgrade always to the latest version. That's the ideal world :) Yours René
Re: [DISCUSS] LTS releases?
Sebastien, So wouldn't it be nice to make clear which release is still supported and which release is not? On 03.07.2015 09:20, sebgoa wrote: I think we got in a situation with 4.4 that called for us to keep maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release. Your are saying 4.3 is a good release, shouldn't it be maintained a bit longer? So currently we have: main 4.5.x stable: 4.4.x legacy: 4.3.x deprecated: 4.2.0 When 4.6 is released, what should a release be dropped? 4.4.x? main: 4.6.0 stable: 4.5.x legacy: 4.3.x What is your plan about this? Yours René
Re: [DISCUSS] LTS releases?
Bug fixing in older releases is actually a lot of work. For security related issues we could maybe do it. Personally, I prefer to have a fast release cycle and smooth (tested) upgrade paths over 2-year LTS release cycle. It's more agile. As a bonus, people get the new features. The more people do upgrades that work (tm) the more confident they are. I'd really want to show that upgrades work so well that we need no LTS. But there might be other reasons people have where LTS would help. Please share! Regards, Remi On 02 Jul 2015, at 16:25, Rene Moser m...@renemoser.net wrote: Maybe a little bit off topic to the new release process, therefor a new thread... speaking about releases. I just thought about supporting LTS releases. This would mean someone or we make a commitment to add bug fixes (only) for a specified time. e.g. 2 years for a release or until the next LTS release? Would this something anyone would be interested in? Yours René
Re: [DISCUSS] LTS Releases
Hi everyone, Thanks for a great discussion. I understand it may be difficult to support releases for several years with CloudStack’s fast paced development, and the statistics Leo shared are certainly not what I was aiming for. I think it will be difficult to gather agreement in this stage and I certainly don’t want to hurt upstream in any way so I think it’s alright to simply keep doing bugfix releases without labelling them with anything on the upstream project. From ShapeBlue’s standpoint we will keep working on the upstream first and make sure we don’t fork CloudStack though we’ll have our support branches but those will be public too (https://github.com/shapeblue/cloudstack). We’ll be driving bugfix releases and if those releases are not possible (due to lack of upgrade paths to later/future versions say in 4.4.1, 4.4.2 etc) we’ll keep releasing our patches with suitable release notes publicly via our deb/rpm repositories publicly (shapeblue.com/packages) for everyone. On 28-Nov-2014, at 3:17 pm, Leo Simons lsim...@schubergphilis.com wrote: Hey hey, Ooh, interesting topic. I'm going to top-post because I want to focus on the big picture! * Apache HTTPD provides 8+ years of support for old releases. * Tomcat provides 6+ years of support for N-2 release. * Ant provides 12+ years of backward compatiblity, so far. (details below) I think this is great and when I was proud of apache it was usually because of stuff like that. Every now and then I get a support enquiry about code that has been in the attic for many many years, and I always take the time to answer it, even if I've almost forgotten about collections pre java 1.2. This lng term support happens because the people that work on those projects want it to happen and do the work to make it happen. Since in this case, you want it to happen, and signed up to do the work, cloudstack its support window (for 4.3) grows. The more people do that, the bigger the support window will get. The 4.3 branch should live as long as people want to work on it and there's enough people to vote to release it. No-one should stop you, and I'd be a little upset if someone tried. This can happen naturally: it doesn't actually *need* a model or a discussion, just people to do the work and enough people to vote to release that work. You see a need here, you're stepping in to fill that need, so, thanks for volunteering (no sarcasm). I personally believe such explicit support models and commitments can hurt for 'upstreams' (*). If you look at the httpd download page, it doesn't say we'll support this for 8 years to come, it just says 'download here'. Users are expected and trusted to evaluate whether the community support is enough, and if it isn't, or they can't figure that out, they should go seek a downstream that provides the support (and typically, warranty and guarantee and indemnification and SLA and ...) that you don't get from an open source project. Ubuntu is a differently shaped project from cloudstack. Ubuntu is a (more unstable...) downstream of debian, where the httpd package is a downstream of httpd.apache.org. The key value of ubuntu LTS is in the tested _aggregation_ of many mutually compatible versions. IMHO. But hey, agreement is absolutely not required! I applaud you for doing what you think is right for your customers and for talking openly about it here. Customers these days tend to be pretty good at spotting who is listening to what they need, so as long as you understood that correctly, I'm sure it's a sound commercial decision for ShapeBlue too :-D cheers, Leo (*) I think in the lng term that quality improvement is best focused on master/tip. Well, at least up to about 80% unit test coverage or so :). My advice would be to ditch all 4.3 work, ditch any further 4.4 work, and invest all that effort into /testing/ for 4.5. Once you have high code velocity, trustable continuous integration and continuous delivery, etc, compatibilitystability are just more things to testmeasure, and they only go up. -- HTTPD * 2002-02-06 first release of apache httpd 2.0 * 2002-02-03 last release of apache httpd 1.3 That's a history of 8 years of support for N-1 major releases. * 2005-11-30 first release of apache httpd 2.2 * 2012-02-19 first release of apache httpd 2.4 * 2013-07-02 last release of apache httpd 2.0 That's a history of 8 years of support for N-1 minor releases. * 2.2 and 2.4 currently still being supported So so far that's 9 years of support for the current N-1 minor release. Of course httpd 2.4 is ~99% backward compatible with httpd 2.0, so that's 12+ years of backwards compatibility. Tomcat * 2004-08-29 first releaes of tomcat 5 * 2006-10-21 first release of tomcat 6 (still supported) * 2011-03-05 first release of tomcat 7 (still supported) * 2012-10-09 last release of tomcat 5 * 2014-02-02 first release
Re: [DISCUSS] LTS Releases
Hey hey, Ooh, interesting topic. I'm going to top-post because I want to focus on the big picture! * Apache HTTPD provides 8+ years of support for old releases. * Tomcat provides 6+ years of support for N-2 release. * Ant provides 12+ years of backward compatiblity, so far. (details below) I think this is great and when I was proud of apache it was usually because of stuff like that. Every now and then I get a support enquiry about code that has been in the attic for many many years, and I always take the time to answer it, even if I've almost forgotten about collections pre java 1.2. This lng term support happens because the people that work on those projects want it to happen and do the work to make it happen. Since in this case, you want it to happen, and signed up to do the work, cloudstack its support window (for 4.3) grows. The more people do that, the bigger the support window will get. The 4.3 branch should live as long as people want to work on it and there's enough people to vote to release it. No-one should stop you, and I'd be a little upset if someone tried. This can happen naturally: it doesn't actually *need* a model or a discussion, just people to do the work and enough people to vote to release that work. You see a need here, you're stepping in to fill that need, so, thanks for volunteering (no sarcasm). I personally believe such explicit support models and commitments can hurt for 'upstreams' (*). If you look at the httpd download page, it doesn't say we'll support this for 8 years to come, it just says 'download here'. Users are expected and trusted to evaluate whether the community support is enough, and if it isn't, or they can't figure that out, they should go seek a downstream that provides the support (and typically, warranty and guarantee and indemnification and SLA and ...) that you don't get from an open source project. Ubuntu is a differently shaped project from cloudstack. Ubuntu is a (more unstable...) downstream of debian, where the httpd package is a downstream of httpd.apache.org. The key value of ubuntu LTS is in the tested _aggregation_ of many mutually compatible versions. IMHO. But hey, agreement is absolutely not required! I applaud you for doing what you think is right for your customers and for talking openly about it here. Customers these days tend to be pretty good at spotting who is listening to what they need, so as long as you understood that correctly, I'm sure it's a sound commercial decision for ShapeBlue too :-D cheers, Leo (*) I think in the lng term that quality improvement is best focused on master/tip. Well, at least up to about 80% unit test coverage or so :). My advice would be to ditch all 4.3 work, ditch any further 4.4 work, and invest all that effort into /testing/ for 4.5. Once you have high code velocity, trustable continuous integration and continuous delivery, etc, compatibilitystability are just more things to testmeasure, and they only go up. -- HTTPD * 2002-02-06 first release of apache httpd 2.0 * 2002-02-03 last release of apache httpd 1.3 That's a history of 8 years of support for N-1 major releases. * 2005-11-30 first release of apache httpd 2.2 * 2012-02-19 first release of apache httpd 2.4 * 2013-07-02 last release of apache httpd 2.0 That's a history of 8 years of support for N-1 minor releases. * 2.2 and 2.4 currently still being supported So so far that's 9 years of support for the current N-1 minor release. Of course httpd 2.4 is ~99% backward compatible with httpd 2.0, so that's 12+ years of backwards compatibility. Tomcat * 2004-08-29 first releaes of tomcat 5 * 2006-10-21 first release of tomcat 6 (still supported) * 2011-03-05 first release of tomcat 7 (still supported) * 2012-10-09 last release of tomcat 5 * 2014-02-02 first release of tomcat 8 So that's a history of 6 years of support for N-2 major releases. Ant * 2003-08-12 first release of ant 1.5 (1.5.2) * 2014-04-30 current release of ant (1.9.4) Ant's been ~99% backward compatible from about ant 1.4, but I can't find a timestamp for ant 1.4. So that's a history of 12 years of backward compatibility.
Re: [DISCUSS] LTS Releases
my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need to consider. I have a very nice experience with CloudStack so far (in general, except being frustrated by some childish problems) - if this was all polished, and documentation complete - I'm 100% sure there will be no better cloud project on the market any time soon, and I really mean it ! It is my wish (and I hope of others) to see CloudStack migrate from #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is VERY much possible. On 26 November 2014 at 22:40, Pierre-Luc Dion pdion...@apache.org wrote: I'm not really in favor of LTS support, it's a good idea, but not sure it can be backed by the community?[open question here ;)]. I don't think it fit in our current model for few reasons: - Upgrade path might become impossible as patches become part of multiple versions. We could end up with problem at database schema with the current db upgrade model. - Enforcing user to stay on a legacy ACS release disallow usage of future hypervisor version, Guest OSes and new hardware used by hypervisors. As hypervisors will become out of date, they won't be able to support new Guest OSes and new hardware. - I think the initiative would dilute the effort on the upgrade path and making sure the upgrade path is easy and always work. Since 4.3.1 as been released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or event 4.5? - Contribution to ACS and bugfixing become nightmare as bugfix might end up in 4 branches (4.3, 4.4, 4.5, master,...) Why not as community (let's face it, not very a big one) we all focus on the next 4.5 version, make sure it's properly tested, make sure upgrade just work and have ACS 4 as the LTS ? ;-) I know a production system is not likely to run the latest version of ACS and upgrade of such a prod tool can occur maybe one or two time a year. That's just my opinion on the subject, nothing against anyone or to block the idea. On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers h...@trippaers.nl wrote: Top posting here as my remarks are mainly on the original topic. I’m not in favor of supporting LTS releases as a community. The reasoning here is that there is a huge chance that we will fragment the community in people that just want to work on the latest and greatest and some other folks who are trying to keep older releases from being updated with newer fixes. It requires a lot of dedicated commitment to keep an LTS release going. Particularly if you yourself are already working with a newer release in your environment. So from a personal standpoint i can almost guarantee that i will probably not spend the time and effort of back porting any fixes i do to older versions of CloudStack. That doesn’t mean that it can’t happen. If people are willing to take charge of an LTS branch and are willing to do the work to back port fixes where appropriate i would happily support them and even try to test the releases so we can have an official release. New developers might also be scared by the fact that a fix they make has to be supported on multiple branches and might decide not to commit such a fix because of the work involved. With the rate of change in the code at the moment this is also very hard for seasoned developers, so much little, but important stuff changes all the time that back porting is very difficult. It is an open source project and generally people will want to focus on the latest and greatest and just get their features in. I’m already regularly having some trouble back porting between master and 4.5. Consider back porting to master, 4.5 and 4.3 as well and having to test each branch. Basically my point is, everyone who wants to LTS support a certain branch is free to do so. Whether or not other contributors or committers will want to do that is their choice. As a community we should not make any promises about LTS support for a certain branch. Cheers, Hugo On 25 nov. 2014, at 16:16, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is
Re: [DISCUSS] LTS Releases
On Nov 27, 2014, at 9:01 AM, Andrija Panic andrija.pa...@gmail.com wrote: my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need to consider. I have a very nice experience with CloudStack so far (in general, except being frustrated by some childish problems) - if this was all polished, and documentation complete - I'm 100% sure there will be no better cloud project on the market any time soon, and I really mean it ! It is my wish (and I hope of others) to see CloudStack migrate from #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is VERY much possible. Thanks for this Andrija, it made my morning :) I am of the opinion that if/when we improve our committing habits, we will have high confidence that every bug fixed in a release branch will also be fixed in the next release. Little process changing that we are making, like using github PR, merging back to master etc, will help us get into somewhat of a rolling release. If we take great care with our upgrade paths and avoid regressions then LTS becomes less important. We have had some challenges with 4.4 and the fact that 4.3 is solid makes it natural to want to keep 4.3 alive and patched. I don't use cloudstack in production so I will differ to those who do on this. What we do need is higher involvement of users in testing and voting on the releases early. -Sebastien On 26 November 2014 at 22:40, Pierre-Luc Dion pdion...@apache.org wrote: I'm not really in favor of LTS support, it's a good idea, but not sure it can be backed by the community?[open question here ;)]. I don't think it fit in our current model for few reasons: - Upgrade path might become impossible as patches become part of multiple versions. We could end up with problem at database schema with the current db upgrade model. - Enforcing user to stay on a legacy ACS release disallow usage of future hypervisor version, Guest OSes and new hardware used by hypervisors. As hypervisors will become out of date, they won't be able to support new Guest OSes and new hardware. - I think the initiative would dilute the effort on the upgrade path and making sure the upgrade path is easy and always work. Since 4.3.1 as been released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or event 4.5? - Contribution to ACS and bugfixing become nightmare as bugfix might end up in 4 branches (4.3, 4.4, 4.5, master,...) Why not as community (let's face it, not very a big one) we all focus on the next 4.5 version, make sure it's properly tested, make sure upgrade just work and have ACS 4 as the LTS ? ;-) I know a production system is not likely to run the latest version of ACS and upgrade of such a prod tool can occur maybe one or two time a year. That's just my opinion on the subject, nothing against anyone or to block the idea. On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers h...@trippaers.nl wrote: Top posting here as my remarks are mainly on the original topic. I’m not in favor of supporting LTS releases as a community. The reasoning here is that there is a huge chance that we will fragment the community in people that just want to work on the latest and greatest and some other folks who are trying to keep older releases from being updated with newer fixes. It requires a lot of dedicated commitment to keep an LTS release going. Particularly if you yourself are already working with a newer release in your environment. So from a personal standpoint i can almost guarantee that i will probably not spend the time and effort of back porting any fixes i do to older versions of CloudStack. That doesn’t mean that it can’t happen. If people are willing to take charge of an LTS branch and are willing to do the work to back port fixes where appropriate i would happily support them and even try to test the releases so we can have an official release. New developers might also be scared by the fact that a fix they make has to be supported on multiple branches and might decide not to commit such a fix because of the work involved. With the rate of change in the code at the moment this is also very hard for seasoned developers, so
Re: [DISCUSS] LTS Releases
hi, LTS means Long Term Support , for ubuntu means 5 years support for both desktop and server distributions. If we adopt to release cloudstack's LTS version , how many years should we support ? 5 years ? of course can not accept ! even 3 years may be too long to old for support as a IAAS management software . 2 or 1 years ? this should not call LTS version . Second ,the time span for ubuntu release next new LTS version is every 2 years . Then , consider the first question , what kind of years interval should we take? Third, even if the above two issues is false positive , how should we name the LTS release version's ? such as: CloudStack-LTS-4.x-201401 , CloudStack-LTS-4.X-201402 etc , this may cause a more confuse to end-users to make a right choice . IMO , if a software could automatically upgrade to newer version by just one or fews clickes , which kind software is suitable for LTS release mechanism , otherwise the cost for end-user to upgrade from the older one to newer which will be same as user to choice next release version, ie reinstall . as Hugo, sebgoa and Andrija said: we need a WAY to focus here on FIXING, POLISHING , then LTS becomes less important and I’m not in favor of supporting LTS releases as a community. -- Regards, ChunFeng -- Original -- From: sebgoarun...@gmail.com; Date: Thu, Nov 27, 2014 05:14 PM To: devdev@cloudstack.apache.org; Subject: Re: [DISCUSS] LTS Releases On Nov 27, 2014, at 9:01 AM, Andrija Panic andrija.pa...@gmail.com wrote: my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need to consider. I have a very nice experience with CloudStack so far (in general, except being frustrated by some childish problems) - if this was all polished, and documentation complete - I'm 100% sure there will be no better cloud project on the market any time soon, and I really mean it ! It is my wish (and I hope of others) to see CloudStack migrate from #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is VERY much possible. Thanks for this Andrija, it made my morning :) I am of the opinion that if/when we improve our committing habits, we will have high confidence that every bug fixed in a release branch will also be fixed in the next release. Little process changing that we are making, like using github PR, merging back to master etc, will help us get into somewhat of a rolling release. If we take great care with our upgrade paths and avoid regressions then LTS becomes less important. We have had some challenges with 4.4 and the fact that 4.3 is solid makes it natural to want to keep 4.3 alive and patched. I don't use cloudstack in production so I will differ to those who do on this. What we do need is higher involvement of users in testing and voting on the releases early. -Sebastien On 26 November 2014 at 22:40, Pierre-Luc Dion pdion...@apache.org wrote: I'm not really in favor of LTS support, it's a good idea, but not sure it can be backed by the community?[open question here ;)]. I don't think it fit in our current model for few reasons: - Upgrade path might become impossible as patches become part of multiple versions. We could end up with problem at database schema with the current db upgrade model. - Enforcing user to stay on a legacy ACS release disallow usage of future hypervisor version, Guest OSes and new hardware used by hypervisors. As hypervisors will become out of date, they won't be able to support new Guest OSes and new hardware. - I think the initiative would dilute the effort on the upgrade path and making sure the upgrade path is easy and always work. Since 4.3.1 as been released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or event 4.5? - Contribution to ACS and bugfixing become nightmare as bugfix might end up in 4 branches (4.3, 4.4, 4.5, master,...) Why not as community (let's face it, not very a big one) we all focus on the next 4.5 version, make sure it's properly tested, make sure upgrade just work and have ACS 4 as the LTS ? ;-) I know a production system is not likely to run
Re: [DISCUSS] LTS Releases
ChunFeng, I think as long as there is a change to the current efforts it will improve the stability of the product. At the moment, it is clearly not working very well for the end users, otherwise, we would not be discussing this topic. As to answer your previous concerns, I agree, having a 5 year support is not an option for CloudStack, especially taking into considering the dynamic development and the current maturity of the product. It has to be more frequent. Perhaps the LTS equivalent version should be released with every two/three releases of the non-LTS release. Two/three release cycles should be enough time to community test the new features and correct the bugs for the stable release. IMHO the naming concept is less important as long as the documentation and release notes make a distinction. Having fancy letters at the end of the product name is a marketing/PR/sales job ). Some companies use LTS, others GA, others simply use odd/even version numbering to distinguish between the production and testing releases. One issue that I foresee with the LTS / non-LTS release cycles is that the non-LTS releases might have a smaller userbase as a lot of users want to have a production ready system and they perhaps be less likely to install and test the non-LTS release. Andrei - Original Message - From: ChunFeng chunf...@domolo.com To: dev dev@cloudstack.apache.org Sent: Thursday, 27 November, 2014 10:36:46 AM Subject: Re: [DISCUSS] LTS Releases hi, LTS means Long Term Support , for ubuntu means 5 years support for both desktop and server distributions. If we adopt to release cloudstack's LTS version , how many years should we support ? 5 years ? of course can not accept ! even 3 years may be too long to old for support as a IAAS management software . 2 or 1 years ? this should not call LTS version . Second ,the time span for ubuntu release next new LTS version is every 2 years . Then , consider the first question , what kind of years interval should we take? Third, even if the above two issues is false positive , how should we name the LTS release version's ? such as: CloudStack-LTS-4.x-201401 , CloudStack-LTS-4.X-201402 etc , this may cause a more confuse to end-users to make a right choice . IMO , if a software could automatically upgrade to newer version by just one or fews clickes , which kind software is suitable for LTS release mechanism , otherwise the cost for end-user to upgrade from the older one to newer which will be same as user to choice next release version, ie reinstall . as Hugo, sebgoa and Andrija said: we need a WAY to focus here on FIXING, POLISHING , then LTS becomes less important and I’m not in favor of supporting LTS releases as a community. -- Regards, ChunFeng -- Original -- From: sebgoarun...@gmail.com; Date: Thu, Nov 27, 2014 05:14 PM To: devdev@cloudstack.apache.org; Subject: Re: [DISCUSS] LTS Releases On Nov 27, 2014, at 9:01 AM, Andrija Panic andrija.pa...@gmail.com wrote: my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need to consider. I have a very nice experience with CloudStack so far (in general, except being frustrated by some childish problems) - if this was all polished, and documentation complete - I'm 100% sure there will be no better cloud project on the market any time soon, and I really mean it ! It is my wish (and I hope of others) to see CloudStack migrate from #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is VERY much possible. Thanks for this Andrija, it made my morning :) I am of the opinion that if/when we improve our committing habits, we will have high confidence that every bug fixed in a release branch will also be fixed in the next release. Little process changing that we are making, like using github PR, merging back to master etc, will help us get into somewhat of a rolling release. If we take great care with our upgrade paths and avoid regressions then LTS becomes less important. We have had some challenges with 4.4 and the fact that 4.3 is solid makes it natural to want
Re: [DISCUSS] LTS Releases
Thanks to Rohit Andrei shares focus on this topic . I am +1 on we should reshape the rhythm of new release . btw, http://en.wikipedia.org/wiki/Linux_kernel Since the 2004 release of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release cycle. In 2004, after version 2.6.0 was released, the kernel developers held several discussions regarding the release and version scheme[200][201] and ultimately Linus Torvalds and others decided that a much shorter time-based release cycle would be beneficial. The even-odd system of alternation between stable and unstable was gone. Instead, development pre-releases are titled release candidates, which is indicated by appending the suffix '-rc' to the kernel version, followed by an ordinal number. -- Regards, ChunFeng -- Original -- From: Andrei Mikhailovskyand...@arhont.com; Date: Thu, Nov 27, 2014 08:51 PM To: devdev@cloudstack.apache.org; Subject: Re: [DISCUSS] LTS Releases ChunFeng, I think as long as there is a change to the current efforts it will improve the stability of the product. At the moment, it is clearly not working very well for the end users, otherwise, we would not be discussing this topic. As to answer your previous concerns, I agree, having a 5 year support is not an option for CloudStack, especially taking into considering the dynamic development and the current maturity of the product. It has to be more frequent. Perhaps the LTS equivalent version should be released with every two/three releases of the non-LTS release. Two/three release cycles should be enough time to community test the new features and correct the bugs for the stable release. IMHO the naming concept is less important as long as the documentation and release notes make a distinction. Having fancy letters at the end of the product name is a marketing/PR/sales job ). Some companies use LTS, others GA, others simply use odd/even version numbering to distinguish between the production and testing releases. One issue that I foresee with the LTS / non-LTS release cycles is that the non-LTS releases might have a smaller userbase as a lot of users want to have a production ready system and they perhaps be less likely to install and test the non-LTS release. Andrei - Original Message - From: ChunFeng chunf...@domolo.com To: dev dev@cloudstack.apache.org Sent: Thursday, 27 November, 2014 10:36:46 AM Subject: Re: [DISCUSS] LTS Releases hi, LTS means Long Term Support , for ubuntu means 5 years support for both desktop and server distributions. If we adopt to release cloudstack's LTS version , how many years should we support ? 5 years ? of course can not accept ! even 3 years may be too long to old for support as a IAAS management software . 2 or 1 years ? this should not call LTS version . Second ,the time span for ubuntu release next new LTS version is every 2 years . Then , consider the first question , what kind of years interval should we take? Third, even if the above two issues is false positive , how should we name the LTS release version's ? such as: CloudStack-LTS-4.x-201401 , CloudStack-LTS-4.X-201402 etc , this may cause a more confuse to end-users to make a right choice . IMO , if a software could automatically upgrade to newer version by just one or fews clickes , which kind software is suitable for LTS release mechanism , otherwise the cost for end-user to upgrade from the older one to newer which will be same as user to choice next release version, ie reinstall . as Hugo, sebgoa and Andrija said: we need a WAY to focus here on FIXING, POLISHING , then LTS becomes less important and I’m not in favor of supporting LTS releases as a community. -- Regards, ChunFeng -- Original -- From: sebgoarun...@gmail.com; Date: Thu, Nov 27, 2014 05:14 PM To: devdev@cloudstack.apache.org; Subject: Re: [DISCUSS] LTS Releases On Nov 27, 2014, at 9:01 AM, Andrija Panic andrija.pa...@gmail.com wrote: my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need
Re: [DISCUSS] LTS Releases
I'm not really in favor of LTS support, it's a good idea, but not sure it can be backed by the community?[open question here ;)]. I don't think it fit in our current model for few reasons: - Upgrade path might become impossible as patches become part of multiple versions. We could end up with problem at database schema with the current db upgrade model. - Enforcing user to stay on a legacy ACS release disallow usage of future hypervisor version, Guest OSes and new hardware used by hypervisors. As hypervisors will become out of date, they won't be able to support new Guest OSes and new hardware. - I think the initiative would dilute the effort on the upgrade path and making sure the upgrade path is easy and always work. Since 4.3.1 as been released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or event 4.5? - Contribution to ACS and bugfixing become nightmare as bugfix might end up in 4 branches (4.3, 4.4, 4.5, master,...) Why not as community (let's face it, not very a big one) we all focus on the next 4.5 version, make sure it's properly tested, make sure upgrade just work and have ACS 4 as the LTS ? ;-) I know a production system is not likely to run the latest version of ACS and upgrade of such a prod tool can occur maybe one or two time a year. That's just my opinion on the subject, nothing against anyone or to block the idea. On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers h...@trippaers.nl wrote: Top posting here as my remarks are mainly on the original topic. I’m not in favor of supporting LTS releases as a community. The reasoning here is that there is a huge chance that we will fragment the community in people that just want to work on the latest and greatest and some other folks who are trying to keep older releases from being updated with newer fixes. It requires a lot of dedicated commitment to keep an LTS release going. Particularly if you yourself are already working with a newer release in your environment. So from a personal standpoint i can almost guarantee that i will probably not spend the time and effort of back porting any fixes i do to older versions of CloudStack. That doesn’t mean that it can’t happen. If people are willing to take charge of an LTS branch and are willing to do the work to back port fixes where appropriate i would happily support them and even try to test the releases so we can have an official release. New developers might also be scared by the fact that a fix they make has to be supported on multiple branches and might decide not to commit such a fix because of the work involved. With the rate of change in the code at the moment this is also very hard for seasoned developers, so much little, but important stuff changes all the time that back porting is very difficult. It is an open source project and generally people will want to focus on the latest and greatest and just get their features in. I’m already regularly having some trouble back porting between master and 4.5. Consider back porting to master, 4.5 and 4.3 as well and having to test each branch. Basically my point is, everyone who wants to LTS support a certain branch is free to do so. Whether or not other contributors or committers will want to do that is their choice. As a community we should not make any promises about LTS support for a certain branch. Cheers, Hugo On 25 nov. 2014, at 16:16, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. Looks like you skimmed my email and missed the following from my previous email: “Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it.” 4.4.x is probably the greatest ACS feature release ever but I would still recommend conservative users (who consult me) to stick to 4.3.x for production since we know it just works with least amount of pain. The other issue is I know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s customers) want to have bugfix releases and they may not want to migrate to 4.4.x right now since 4.5.x is about 2–3 months away. ACS when consumed by enterprise companies has a typical lifecycle that lasts at least 6 months, that means someone needs to support it, therefore the idea of official LTS releases. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. In any form I did not say anything about not helping out or not porting things.
Re: [DISCUSS] LTS Releases
Hi, On 11/25/2014 12:30 PM, Rohit Yadav wrote: Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. I'm not against it at all, I think that a lot of end-users would really want this. But aren't we a bit to soon? I agree that 4.3 is a good version which is out there and 4.4.2 seems to be as well, but where do we make the decision? I think that we should have master more stable before we can do this. Backporting things from master to 4.3 is already a time consuming job due to the big differences between the branches. At PCextreme we run on 4.3 with our own homebrew version where we got some patches from master to 4.3, but that is already taking a lot of time. Wido Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] LTS Releases
Like Wido, I also agree with LTS, but also think 4.3 is kind of old by now and 4.4.2 is looking good. Perhaps take a step back and see how 4.5 goes and start with that one? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 11:30:53 Subject: [DISCUSS] LTS Releases Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] LTS Releases
Hi Wido and Lucian, There are many ways to get to a stable product including fixing coverity issues, unit/integration tests etc. but one of those ways is to simply support existing releases with bugfix releases because most CloudStack users just don’t care about git workflows, or coverity or unit/integration tests, they simply expect it to work and if it has bugs they expect them to be fixed. We don’t have production usage data and feedback from users to conclude that 4.4.x releases are stable enough. Some of them (include our customers) have tried to upgrade their test prod. environments from 4.3.x to 4.4.x and have failed. So we decided to put backporting/testing efforts on 4.3 which we have confidence that it just works until a stable 4.5.x on which we have a certain confidence is released. Just to put out a note here - many smart and active contributors/users may know their way around CloudStack such as Wido/PCExtreme and Lucian, but many large/serious CloudStack users are slow to change and upgrading every 3-4 months may not be an option for them. I know quite a few users who are operating large clouds and are still on ACS 4.2.x. This simply means they are not going to simply upgrade just because there is a new release with lots of new features. Therefore the idea of supporting those releases until we have a confidence of a new stable release. Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it. The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. I anticipate that 4.5.0 should be out in about 2 months time around Jan/Feb 2015. With this anticipation and known confidence of 4.3.x in production at ShapeBlue we decided to support 4.3 branch until a stable 4.5.x branch is out. On 25-Nov-2014, at 6:39 pm, Nux! n...@li.nux.ro wrote: Like Wido, I also agree with LTS, but also think 4.3 is kind of old by now and 4.4.2 is looking good. Perhaps take a step back and see how 4.5 goes and start with that one? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 11:30:53 Subject: [DISCUSS] LTS Releases Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
Re: [DISCUSS] LTS Releases
On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
Re: [DISCUSS] LTS Releases
Rohit, Agreed, I know very well how it is to get stuck with a certain version and your (and everyone's) need for backports. Your decision re 4.3 seems to make sense, it looks in good (blue?) shape. 4.5 is starting to look very interesting. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:40:23 Subject: Re: [DISCUSS] LTS Releases Hi Wido and Lucian, There are many ways to get to a stable product including fixing coverity issues, unit/integration tests etc. but one of those ways is to simply support existing releases with bugfix releases because most CloudStack users just don’t care about git workflows, or coverity or unit/integration tests, they simply expect it to work and if it has bugs they expect them to be fixed. We don’t have production usage data and feedback from users to conclude that 4.4.x releases are stable enough. Some of them (include our customers) have tried to upgrade their test prod. environments from 4.3.x to 4.4.x and have failed. So we decided to put backporting/testing efforts on 4.3 which we have confidence that it just works until a stable 4.5.x on which we have a certain confidence is released. Just to put out a note here - many smart and active contributors/users may know their way around CloudStack such as Wido/PCExtreme and Lucian, but many large/serious CloudStack users are slow to change and upgrading every 3-4 months may not be an option for them. I know quite a few users who are operating large clouds and are still on ACS 4.2.x. This simply means they are not going to simply upgrade just because there is a new release with lots of new features. Therefore the idea of supporting those releases until we have a confidence of a new stable release. Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it. The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. I anticipate that 4.5.0 should be out in about 2 months time around Jan/Feb 2015. With this anticipation and known confidence of 4.3.x in production at ShapeBlue we decided to support 4.3 branch until a stable 4.5.x branch is out.
Re: [DISCUSS] LTS Releases
Daan, I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:56:12 Subject: Re: [DISCUSS] LTS Releases On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
RE: [DISCUSS] LTS Releases
I do prefer 4.4 as well because it has GPU sharing and we actively test it. Other bugs are not so important for us right now. Vadim. -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Tuesday, November 25, 2014 4:48 PM To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: Re: [DISCUSS] LTS Releases Daan, I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:56:12 Subject: Re: [DISCUSS] LTS Releases On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
Re: [DISCUSS] LTS Releases
On Tue, Nov 25, 2014 at 3:47 PM, Nux! n...@li.nux.ro wrote: I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) It makes me feel the hero;) Seriously, I don't feel bad about 4.4, but I am worried of a legacy of 4.3 being created were 4.4 effectively becomes a fork of the product while 4.3 keeps converging back to 4.5. Rohit is putting tremendous effort into 4.3 that I will certainly not put into 4.4. I don't mind doing some convergence work. This is not our use case. I don't want to compete with Rohit. I raise the subject because of my concerns for the project. -- Daan
Re: [DISCUSS] LTS Releases
Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. Looks like you skimmed my email and missed the following from my previous email: “Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it.” 4.4.x is probably the greatest ACS feature release ever but I would still recommend conservative users (who consult me) to stick to 4.3.x for production since we know it just works with least amount of pain. The other issue is I know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s customers) want to have bugfix releases and they may not want to migrate to 4.4.x right now since 4.5.x is about 2–3 months away. ACS when consumed by enterprise companies has a typical lifecycle that lasts at least 6 months, that means someone needs to support it, therefore the idea of official LTS releases. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. In any form I did not say anything about not helping out or not porting things. People who know me, know that I love to help everyone and I’m quite prompt at reply and resolving things. I’ve taken the task to maintain 4.3 and you’re very welcome to go thorough JIRA etc. to backport things that you want for 4.4 since you’re alone the gatekeeper of this branch. I’m going through these bugs that have a different fix version (not 4.3.0 or 4.3.1): https://issues.apache.org/jira/issues/?filter=12329775 Wido suggested that backporting is time consuming so as a challenge I’ve went through 50 issues today, I was able to understand/backport about 25 of them that qualified for 4.3 branch (many of them were trivial, https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f72eb945540e607ff25917922b4084187246f31a), about 10 of them were hard to backport so I’ve asked authors to help out. I think with this speed I alone should be able to go through like 300 issues reported on JIRA in about 10-15 days time and after than about 10-20 days of testing and getting the bugfix release out. Though if we all help out we can get more mileage. It sucks for me personally that I’ve been emailing you privately about cherry-pick and asking you to pick them on 4.4 (also leaving messages on JIRA). I’ll continue to do that :) and meanwhile, you are very welcome to go see the things I picked on 4.3 and pick those applicable on 4.4. Yours friendly and as always, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] LTS Releases
Rohit, I consider you my friend and colleague, I could reply on everything said but do not want to escalate on all the details. The only remark I want to make is that 4.4 is open for commits from here on in. On Tue, Nov 25, 2014 at 4:16 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: -- Daan
Re: [DISCUSS] LTS Releases
Top posting here as my remarks are mainly on the original topic. I’m not in favor of supporting LTS releases as a community. The reasoning here is that there is a huge chance that we will fragment the community in people that just want to work on the latest and greatest and some other folks who are trying to keep older releases from being updated with newer fixes. It requires a lot of dedicated commitment to keep an LTS release going. Particularly if you yourself are already working with a newer release in your environment. So from a personal standpoint i can almost guarantee that i will probably not spend the time and effort of back porting any fixes i do to older versions of CloudStack. That doesn’t mean that it can’t happen. If people are willing to take charge of an LTS branch and are willing to do the work to back port fixes where appropriate i would happily support them and even try to test the releases so we can have an official release. New developers might also be scared by the fact that a fix they make has to be supported on multiple branches and might decide not to commit such a fix because of the work involved. With the rate of change in the code at the moment this is also very hard for seasoned developers, so much little, but important stuff changes all the time that back porting is very difficult. It is an open source project and generally people will want to focus on the latest and greatest and just get their features in. I’m already regularly having some trouble back porting between master and 4.5. Consider back porting to master, 4.5 and 4.3 as well and having to test each branch. Basically my point is, everyone who wants to LTS support a certain branch is free to do so. Whether or not other contributors or committers will want to do that is their choice. As a community we should not make any promises about LTS support for a certain branch. Cheers, Hugo On 25 nov. 2014, at 16:16, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. Looks like you skimmed my email and missed the following from my previous email: “Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it.” 4.4.x is probably the greatest ACS feature release ever but I would still recommend conservative users (who consult me) to stick to 4.3.x for production since we know it just works with least amount of pain. The other issue is I know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s customers) want to have bugfix releases and they may not want to migrate to 4.4.x right now since 4.5.x is about 2–3 months away. ACS when consumed by enterprise companies has a typical lifecycle that lasts at least 6 months, that means someone needs to support it, therefore the idea of official LTS releases. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. In any form I did not say anything about not helping out or not porting things. People who know me, know that I love to help everyone and I’m quite prompt at reply and resolving things. I’ve taken the task to maintain 4.3 and you’re very welcome to go thorough JIRA etc. to backport things that you want for 4.4 since you’re alone the gatekeeper of this branch. I’m going through these bugs that have a different fix version (not 4.3.0 or 4.3.1): https://issues.apache.org/jira/issues/?filter=12329775 Wido suggested that backporting is time consuming so as a challenge I’ve went through 50 issues today, I was able to understand/backport about 25 of them that qualified for 4.3 branch (many of them were trivial, https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f72eb945540e607ff25917922b4084187246f31a), about 10 of them were hard to backport so I’ve asked authors to help out. I think with this speed I alone should be able to go through like 300 issues reported on JIRA in about 10-15 days time and after than about 10-20 days of testing and getting the bugfix release out. Though if we all help out we can get more mileage. It sucks for me personally that I’ve been emailing you privately about cherry-pick and asking you to pick them on 4.4 (also leaving messages on JIRA). I’ll continue to do that :) and meanwhile, you are very welcome to go see the things I picked on 4.3 and pick those applicable on 4.4. Yours friendly and as always, Rohit Yadav Software Architect, ShapeBlue
Re: [DISCUSS] LTS Releases
- Original Message - Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. +1 with everything. It is essential for the end users to have a bug fix releases instead of waiting for the next release to come. I've noticed that with CloudStack project majority of latest releases have been delayed from their initial estimated dates. This creates a lot of false expectations and false hopes for the end users who are waiting for the bug fixes. I guess a lot of productions users would rather see a bug being fixed than get a bunch of new features, which are likely to be broken or unpolished in the first release. Also, new releases are likely to introduce additional issues upon upgrading forcing people to downgrade back to their old releases with old unfixed bugs. The LTS release would solve a lot of issues and frustrations and should actually be beneficial to the project and community. In my opinion the Ubuntu team has captured the releases cycles perfectly well. Perhaps ACS should have a stable release every 2 years and a testing release every 2 or 4 quarters. This way, the users will be happy to have a solid backported platform that they can run in production and the developers will be happy working on a new feature set. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. Kudos to ShapeBlue team!!! Many thanks for your contributions and help on promoting this project. I love you guys!!! In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from
