You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <ro...@shapeblue.com> on 2014/11/25 12:30:53 UTC
[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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Daan Hoogland <da...@gmail.com>.
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 <ro...@shapeblue.com> wrote:
> Hey Daan,
>
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@gmail.com> wrote:
--
Daan
Re: [DISCUSS] LTS Releases
Posted by Daan Hoogland <da...@gmail.com>.
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 <ro...@shapeblue.com> wrote:
> Hey Daan,
>
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@gmail.com> wrote:
--
Daan
Re: [DISCUSS] LTS Releases
Posted by ChunFeng <ch...@domolo.com>.
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 Mikhailovsky"<an...@arhont.com>;
Date: Thu, Nov 27, 2014 08:51 PM
To: "dev"<de...@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" <ch...@domolo.com>
> To: "dev" <de...@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"<ru...@gmail.com>;
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev"<de...@cloudstack.apache.org>;
> Subject: Re: [DISCUSS] LTS Releases
> On Nov 27, 2014, at 9:01 AM, Andrija Panic <an...@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 <pd...@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
> >> <hu...@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
> >>>> <ro...@shapeblue.com>
> >>> wrote:
> >>>>
> >>>> Hey Daan,
> >>>>
> >>>>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland
> >>>>> <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by Andrei Mikhailovsky <an...@arhont.com>.
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" <ch...@domolo.com>
> To: "dev" <de...@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"<ru...@gmail.com>;
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev"<de...@cloudstack.apache.org>;
> Subject: Re: [DISCUSS] LTS Releases
> On Nov 27, 2014, at 9:01 AM, Andrija Panic <an...@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 <pd...@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
> >> <hu...@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
> >>>> <ro...@shapeblue.com>
> >>> wrote:
> >>>>
> >>>> Hey Daan,
> >>>>
> >>>>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland
> >>>>> <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by Andrei Mikhailovsky <an...@arhont.com>.
+1
Agree with everything that Andrija have said.
The community needs to divert their attention and focus ever so slightly from producing new features to producing a more stable release. Having the LTS releases will capture this approach and will make the product more stable as fresh and less tested features will not be backported and only the fixes will be contributed. Only the dev team has the capability of actually debugging and fixing the issues.
I am not a developer and can only contribute to the existing bugs or create new bug reports, which I have done in the past. It is very frustrating from a user perspective to see some of the bugs which are effecting their environments not being addressed in new releases. I will try for myself to find more time for testing new releases and report back the issues, but I will not do this on production anymore. I've already had to downgrade my environment 3 times because of the problems with the latest releases. From what I can see, 4.4.1 is no different from the last couple of unlucky releases, with many upgrade problem reports on the user list.
>From what I can see, ShapeBlue team is doing a great job at backporting issues already and I hope many developers will join this effort.
Andrei
----- Original Message -----
> From: "Andrija Panic" <an...@gmail.com>
> To: dev@cloudstack.apache.org
> Sent: Thursday, 27 November, 2014 8:01:41 AM
> Subject: 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 <pd...@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
> > <hu...@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
> > > > <ro...@shapeblue.com>
> > > wrote:
> > > >
> > > > Hey Daan,
> > > >
> > > >> On 25-Nov-2014, at 7:26 pm, Daan Hoogland
> > > >> <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by ChunFeng <ch...@domolo.com>.
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"<ru...@gmail.com>;
Date: Thu, Nov 27, 2014 05:14 PM
To: "dev"<de...@cloudstack.apache.org>;
Subject: Re: [DISCUSS] LTS Releases
On Nov 27, 2014, at 9:01 AM, Andrija Panic <an...@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 <pd...@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 <hu...@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 <ro...@shapeblue.com>
>>> wrote:
>>>>
>>>> Hey Daan,
>>>>
>>>>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by sebgoa <ru...@gmail.com>.
On Nov 27, 2014, at 9:01 AM, Andrija Panic <an...@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 <pd...@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 <hu...@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 <ro...@shapeblue.com>
>>> wrote:
>>>>
>>>> Hey Daan,
>>>>
>>>>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by Andrija Panic <an...@gmail.com>.
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 <pd...@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 <hu...@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 <ro...@shapeblue.com>
> > wrote:
> > >
> > > Hey Daan,
> > >
> > >> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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ć
Re: [DISCUSS] LTS Releases
Posted by Pierre-Luc Dion <pd...@apache.org>.
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 <hu...@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 <ro...@shapeblue.com>
> wrote:
> >
> > Hey Daan,
> >
> >> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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.
>
>
Re: [DISCUSS] LTS Releases
Posted by Hugo Trippaers <hu...@trippaers.nl>.
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 <ro...@shapeblue.com> wrote:
>
> Hey Daan,
>
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Hugo Trippaers <hu...@trippaers.nl>.
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 <ro...@shapeblue.com> wrote:
>
> Hey Daan,
>
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hey Daan,
> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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.
RE: [DISCUSS] LTS Releases
Posted by Vadim Kimlaychuk <Va...@Elion.ee>.
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:nux@li.nux.ro]
Sent: Tuesday, November 25, 2014 4:48 PM
To: dev@cloudstack.apache.org
Cc: users@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" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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 <ro...@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
Posted by Daan Hoogland <da...@gmail.com>.
On Tue, Nov 25, 2014 at 3:47 PM, Nux! <nu...@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
Posted by Vadim Kimlaychuk <Va...@Elion.ee>.
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:nux@li.nux.ro]
Sent: Tuesday, November 25, 2014 4:48 PM
To: dev@cloudstack.apache.org
Cc: users@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" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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 <ro...@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
Posted by Daan Hoogland <da...@gmail.com>.
On Tue, Nov 25, 2014 at 3:47 PM, Nux! <nu...@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
Posted by Nux! <nu...@li.nux.ro>.
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" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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 <ro...@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
Posted by Nux! <nu...@li.nux.ro>.
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" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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 <ro...@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
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hey Daan,
> On 25-Nov-2014, at 7:26 pm, Daan Hoogland <da...@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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Daan Hoogland <da...@gmail.com>.
On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav <ro...@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
Posted by Nux! <nu...@li.nux.ro>.
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" <ro...@shapeblue.com>
> To: users@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
Posted by Daan Hoogland <da...@gmail.com>.
On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav <ro...@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
Posted by Nux! <nu...@li.nux.ro>.
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" <ro...@shapeblue.com>
> To: users@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
Posted by Rohit Yadav <ro...@shapeblue.com>.
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! <nu...@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" <ro...@shapeblue.com>
>> To: "dev" <de...@cloudstack.apache.org>
>> Cc: users@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.yadav@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.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Rohit Yadav <ro...@shapeblue.com>.
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! <nu...@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" <ro...@shapeblue.com>
>> To: "dev" <de...@cloudstack.apache.org>
>> Cc: users@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.yadav@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.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Nux! <nu...@li.nux.ro>.
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" <ro...@shapeblue.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Nux! <nu...@li.nux.ro>.
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" <ro...@shapeblue.com>
> To: "dev" <de...@cloudstack.apache.org>
> Cc: users@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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <LS...@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 loooong 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 loooong 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, compatibility&stability are just more things to test&measure, 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.
>
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <LS...@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 loooong 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 loooong 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, compatibility&stability are just more things to test&measure, 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.
>
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Leo Simons <LS...@schubergphilis.com>.
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 loooong 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 loooong 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, compatibility&stability are just more things to test&measure, 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
Posted by Andrei Mikhailovsky <an...@arhont.com>.
----- 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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Andrei Mikhailovsky <an...@arhont.com>.
----- 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.yadav@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.
Re: [DISCUSS] LTS Releases
Posted by Wido den Hollander <wi...@widodh.nl>.
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.yadav@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.
>