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: "sebgoa"<run...@gmail.com>; > Date: Thu, Nov 27, 2014 05:14 PM > To: "dev"<dev@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 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. 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 & Build< > >>> http://shapeblue.com/iaas-cloud-design-and-build//> > >>>> CSForge – rapid IaaS deployment framework< > >> http://shapeblue.com/csforge/> > >>>> CloudStack > >>>> Consulting<http://shapeblue.com/cloudstack-consultancy/> > >>>> CloudStack Software Engineering< > >>> http://shapeblue.com/cloudstack-software-engineering/> > >>>> CloudStack Infrastructure Support< > >>> http://shapeblue.com/cloudstack-infrastructure-support/> > >>>> CloudStack Bootcamp Training Courses< > >>> http://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. > >>> > >>> > >> > > > > > > > > -- > > > > Andrija Panić
