Re: [DISCUSS] LTS releases?

[Remi Bergsma]

Agree with the ideal world scenario :-)

If we look at it from the other side: Why is it that people want to stay on 
older releases?

From personal experience I know that in the beginning the 4.4 release wasn’t 
that stable. I upgraded production systems from 4.3.0 to 4.4.2 and it was 
painful. That is not true anymore today, as 4.4.4 is pretty nice. From what I 
hear, 4.5.1 is also doing well. Great steps have been made already to make sure 
this will not happen again.

Still, I can imagine that this may have scared some people and it made them 
stay where they are (at 4.3). Let’s investigate if people running 4.3 want to 
upgrade to 4.5.x or the upcoming 4.6 and, more important, why not? Then let’s 
fix that or prove it works.

Regards,
Remi


> What is *our* plan :)
> 
> We used to only maintain the last two major releases.
> 
> We diverged from that model when 4.5.0 came out and that we still wanted to 
> maintain 4.3 because 4.3 was working so well for people.
> 
> My personal preference would be to get into a rolling release model, where we 
> maintain only the last major release.
> This is why making master stable and the base for all our releases is so 
> important.
> 
> Users should get into a model where they continuously upgrade/deploy and 
> don't get stuck on a unmaintained branch with forks that prevents upgrade.
> 
> When users face an issue, we patch and release, then they upgrade always to 
> the latest version.
> 
> That's the ideal world :)

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 3, 2015, at 11:13 AM, Rene Moser  wrote:

> Sebastien,
> 
> So wouldn't it be nice to make clear which release is still supported
> and which release is not?
> 
> On 03.07.2015 09:20, sebgoa wrote:
> 
>> I think we got in a situation with 4.4 that called for us to keep 
>> maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a 
>> good release.
> 
> Your are saying 4.3 is a good release, shouldn't it be maintained a bit
> "longer"?
> 
> So currently we have:
> 
> main 4.5.x
> stable: 4.4.x
> legacy: 4.3.x
> deprecated: 4.2.0
> 
> When 4.6 is released, what should a release be dropped? 4.4.x?
> 
> main: 4.6.0
> stable: 4.5.x
> legacy: 4.3.x
> 
> What is your plan about this?

What is *our* plan :)

We used to only maintain the last two major releases.

We diverged from that model when 4.5.0 came out and that we still wanted to 
maintain 4.3 because 4.3 was working so well for people.

My personal preference would be to get into a rolling release model, where we 
maintain only the last major release.
This is why making master stable and the base for all our releases is so 
important.

Users should get into a model where they continuously upgrade/deploy and don't 
get stuck on a unmaintained branch with forks that prevents upgrade.

When users face an issue, we patch and release, then they upgrade always to the 
latest version.

That's the ideal world :)

> 
> Yours
> René
> 

Re: [DISCUSS] LTS releases?

[Rene Moser]

Sebastien,

So wouldn't it be nice to make clear which release is still supported
and which release is not?

On 03.07.2015 09:20, sebgoa wrote:

> I think we got in a situation with 4.4 that called for us to keep maintaining 
> 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release.

Your are saying 4.3 is a good release, shouldn't it be maintained a bit
"longer"?

So currently we have:

main 4.5.x
stable: 4.4.x
legacy: 4.3.x
deprecated: 4.2.0

When 4.6 is released, what should a release be dropped? 4.4.x?

main: 4.6.0
stable: 4.5.x
legacy: 4.3.x

What is your plan about this?

Yours
René

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 2, 2015, at 4:58 PM, Remi Bergsma  wrote:

> Bug fixing in older releases is actually a lot of work. For security related 
> issues we could maybe do it. 
> 
> Personally, I prefer to have a fast release cycle and smooth (tested) upgrade 
> paths over 2-year LTS release cycle. It's more agile. As a bonus, people get 
> the new features. 
> 
> The more people do upgrades that work (tm) the more confident they are. I'd 
> really want to show that upgrades work so well that we need no LTS. 
> 
> But there might be other reasons people have where LTS would help. Please 
> share!
> 
> Regards, Remi 

I think we got in a situation with 4.4 that called for us to keep maintaining 
4.3….and even after 4.5 was released. Because 4.3 was seen as a good release.

Now that we have 4.4 and 4.5.2 etc, I don't think we will have the cycles to 
maintain that many release branches.

The big issue is upgrade path, 

IMHO our LTS strategy is to have master as a release branch itself, adopt good 
practice to merge to master, have great upgrades and no regressions.

Ultimately we should divert our efforts to master.

So I am +1 with Remi on this.

> 
> 
>> On 02 Jul 2015, at 16:25, Rene Moser  wrote:
>> 
>> Maybe a little bit off topic to the new release process, therefor a new
>> thread...
>> 
>> speaking about releases. I just thought about supporting LTS releases.
>> 
>> This would mean "someone" or "we" make a commitment to add bug fixes
>> (only) for a specified time. e.g. 2 years for a release or until the
>> next LTS release?
>> 
>> Would this something anyone would be interested in?
>> 
>> Yours
>> René

Re: [DISCUSS] LTS releases?

[Remi Bergsma]

Bug fixing in older releases is actually a lot of work. For security related 
issues we could maybe do it. 

Personally, I prefer to have a fast release cycle and smooth (tested) upgrade 
paths over 2-year LTS release cycle. It's more agile. As a bonus, people get 
the new features. 

The more people do upgrades that work (tm) the more confident they are. I'd 
really want to show that upgrades work so well that we need no LTS. 

But there might be other reasons people have where LTS would help. Please share!

Regards, Remi 


> On 02 Jul 2015, at 16:25, Rene Moser  wrote:
> 
> Maybe a little bit off topic to the new release process, therefor a new
> thread...
> 
> speaking about releases. I just thought about supporting LTS releases.
> 
> This would mean "someone" or "we" make a commitment to add bug fixes
> (only) for a specified time. e.g. 2 years for a release or until the
> next LTS release?
> 
> Would this something anyone would be interested in?
> 
> Yours
> René

[DISCUSS] LTS releases?

[Rene Moser]

Maybe a little bit off topic to the new release process, therefor a new
thread...

speaking about releases. I just thought about supporting LTS releases.

This would mean "someone" or "we" make a commitment to add bug fixes
(only) for a specified time. e.g. 2 years for a release or until the
next LTS release?

Would this something anyone would be interested in?

Yours
René

Re: [DISCUSS] LTS Releases

[Rohit Yadav]

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  wrote:
>
> Hey hey,
>
> Ooh, interesting topic. I'm going to top-post because I want to focus on the 
> big picture!
>
> * Apache HTTPD provides 8+ years of support for old releases.
> * Tomcat provides 6+ years of support for N-2 release.
> * Ant provides 12+ years of backward compatiblity, so far.
> (details below)
>
> I think this is great and when I was proud of apache it was usually because 
> of stuff like that. Every now and then I get a support enquiry about code 
> that has been in the attic for many many years, and I always take the time to 
> answer it, even if I've almost forgotten about collections pre java 1.2.
>
> This lng term support happens because the people that work on those 
> projects want it to happen and do the work to make it happen.
>
> Since in this case, you want it to happen, and signed up to do the work, 
> cloudstack its support window (for 4.3) grows. The more people do that, the 
> bigger the support window will get. The 4.3 branch should live as long as 
> people want to work on it and there's enough people to vote to release it. 
> No-one should stop you, and I'd be a little upset if someone tried.
>
> This can happen naturally: it doesn't actually *need* a model or a 
> discussion, just people to do the work and enough people to vote to release 
> that work. You see a need here, you're stepping in to fill that need, so, 
> "thanks for volunteering" (no sarcasm).
>
> I personally believe such explicit support models and commitments can hurt 
> for 'upstreams' (*). If you look at the httpd download page, it doesn't say 
> "we'll support this for 8 years to come", it just says 'download here'. Users 
> are expected and trusted to evaluate whether the community support is enough, 
> and if it isn't, or they can't figure that out, they should go seek a 
> downstream that provides the support (and typically, warranty and guarantee 
> and indemnification and SLA and ...) that you don't get from an open source 
> project.
>
> Ubuntu is a differently shaped project from cloudstack. Ubuntu is a (more 
> unstable...) downstream of debian, where the httpd package is a downstream of 
> httpd.apache.org. The key value of ubuntu LTS is in the tested _aggregation_ 
> of many mutually compatible versions. IMHO.
>
> But hey, agreement is absolutely not required! I applaud you for doing what 
> you think is right for your customers and for talking openly about it here. 
> Customers these days tend to be pretty good at spotting who is listening to 
> what they need, so as long as you understood that correctly, I'm sure it's a 
> sound commercial decision for ShapeBlue too :-D
>
>
> cheers,
>
>
> Leo
>
>
> (*) I think in the lng term that quality improvement is best focused on 
> master/tip. Well, at least up to about 80% unit test coverage or so :). My 
> advice would be to ditch all 4.3 work, ditch any further 4.4 work, and invest 
> all that effort into /testing/ for 4.5. Once you have high code velocity, 
> trustable continuous integration and continuous delivery, etc, 
> 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)

Re: [DISCUSS] LTS Releases

[Leo Simons]

Hey hey,

Ooh, interesting topic. I'm going to top-post because I want to focus on the 
big picture!

* Apache HTTPD provides 8+ years of support for old releases.
* Tomcat provides 6+ years of support for N-2 release.
* Ant provides 12+ years of backward compatiblity, so far.
(details below)

I think this is great and when I was proud of apache it was usually because of 
stuff like that. Every now and then I get a support enquiry about code that has 
been in the attic for many many years, and I always take the time to answer it, 
even if I've almost forgotten about collections pre java 1.2.

This lng term support happens because the people that work on those 
projects want it to happen and do the work to make it happen.

Since in this case, you want it to happen, and signed up to do the work, 
cloudstack its support window (for 4.3) grows. The more people do that, the 
bigger the support window will get. The 4.3 branch should live as long as 
people want to work on it and there's enough people to vote to release it. 
No-one should stop you, and I'd be a little upset if someone tried.

This can happen naturally: it doesn't actually *need* a model or a discussion, 
just people to do the work and enough people to vote to release that work. You 
see a need here, you're stepping in to fill that need, so, "thanks for 
volunteering" (no sarcasm).

I personally believe such explicit support models and commitments can hurt for 
'upstreams' (*). If you look at the httpd download page, it doesn't say "we'll 
support this for 8 years to come", it just says 'download here'. Users are 
expected and trusted to evaluate whether the community support is enough, and 
if it isn't, or they can't figure that out, they should go seek a downstream 
that provides the support (and typically, warranty and guarantee and 
indemnification and SLA and ...) that you don't get from an open source project.

Ubuntu is a differently shaped project from cloudstack. Ubuntu is a (more 
unstable...) downstream of debian, where the httpd package is a downstream of 
httpd.apache.org. The key value of ubuntu LTS is in the tested _aggregation_ of 
many mutually compatible versions. IMHO.

But hey, agreement is absolutely not required! I applaud you for doing what you 
think is right for your customers and for talking openly about it here. 
Customers these days tend to be pretty good at spotting who is listening to 
what they need, so as long as you understood that correctly, I'm sure it's a 
sound commercial decision for ShapeBlue too :-D


cheers,


Leo


(*) I think in the lng term that quality improvement is best focused on 
master/tip. Well, at least up to about 80% unit test coverage or so :). My 
advice would be to ditch all 4.3 work, ditch any further 4.4 work, and invest 
all that effort into /testing/ for 4.5. Once you have high code velocity, 
trustable continuous integration and continuous delivery, etc, 
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

[ChunFeng]

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";
Date:  Thu, Nov 27, 2014 08:51 PM
To:  "dev"; 

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" 
> To: "dev" 
> 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";
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev";

> Subject: Re: [DISCUSS] LTS Releases

> On Nov 27, 2014, at 9:01 AM, Andrija Panic 
> 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 

Re: [DISCUSS] LTS Releases

[Andrei Mikhailovsky]

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" 
> To: "dev" 
> 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";
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev";

> Subject: Re: [DISCUSS] LTS Releases

> On Nov 27, 2014, at 9:01 AM, Andrija Panic 
> 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 hig

Re: [DISCUSS] LTS Releases

[ChunFeng]

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";
Date:  Thu, Nov 27, 2014 05:14 PM
To:  "dev"; 

Subject:  Re: [DISCUSS] LTS Releases

 

On Nov 27, 2014, at 9:01 AM, Andrija Panic  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  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 migh

Re: [DISCUSS] LTS Releases

[Andrei Mikhailovsky]

+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" 
> 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 
> 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
> > 
> > wrote:
> >
> > > Top postin

Re: [DISCUSS] LTS Releases

[sebgoa]

On Nov 27, 2014, at 9:01 AM, Andrija Panic  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  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 
>> 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 invol

Re: [DISCUSS] LTS Releases

[Andrija Panic]

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  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 
> 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 
> > wrote:
> > >
> > > Hey Daan,
> > >
> > >> On 25-No

Re: [DISCUSS] LTS Releases

[Pierre-Luc Dion]

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  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 
> wrote:
> >
> > Hey Daan,
> >
> >> On 25-Nov-2014, at 7:26 pm, Daan Hoogland 
> 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 n

Re: [DISCUSS] LTS Releases

[Andrei Mikhailovsky]

- Original Message -

> Hi,

> During CCCEU14 conference and over emails, I spoke with many
> CloudStack users and I think most of us would like to have and use
> LTS releases. I propose that;

> - We encourage a habit to backport a bugfix to all qualifying
> branches whether or not those branches are LTS
> - We contribute (unit, integration) tests on LTS branches as well on
> other qualifying branches
> - We put correct affect version and fix version on JIRA so issues
> that should be backported to a branch are identified
> - We adapt the LTS release model from Fedora/Ubuntu projects. Please
> share ideas, comments?
> - We officially recognize a LTS release branch, say 4.3 now and
> everyone helps to maintain it, backport bugfixes etc.
> - Until a next latest stable release is published that we all
> mutually agree, we keep working on the LTS branch. After say we have
> a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as
> our next LTS branch and work on it.

> Having a robust product release means we all (developers, users,
> sysadmins, ops etc.) can save time consumed on firefighting a
> CloudStack cloud. Having a LTS branch and releases will get us there
> because on a LTS release/support branch we don’t do feature work at
> all and we only invest time to do bugfixing etc.

+1 with everything. It is essential for the end users to have a bug fix 
releases instead of waiting for the next release to come. I've noticed that 
with CloudStack project majority of latest releases have been delayed from 
their initial estimated dates. This creates a lot of false expectations and 
false hopes for the end users who are waiting for the bug fixes. I guess a lot 
of productions users would rather see a bug being fixed than get a bunch of new 
features, which are likely to be broken or unpolished in the first release. 
Also, new releases are likely to introduce additional issues upon upgrading 
forcing people to downgrade back to their old releases with old unfixed bugs. 
The LTS release would solve a lot of issues and frustrations and should 
actually be beneficial to the project and community. 

In my opinion the Ubuntu team has captured the releases cycles perfectly well. 
Perhaps ACS should have a stable release every 2 years and a testing release 
every 2 or 4 quarters. This way, the users will be happy to have a solid 
backported platform that they can run in production and the developers will be 
happy working on a new feature set. 

> ShapeBlue is already serving their customers with product patching
> service and using our own packages hosting
> (http://shapeblue.com/packages) we publish patches on the “main”
> repository for everyone. We also publish details of the patch we
> publish on our Github wiki, such as this example;
> https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01
> We’ve recently started putting patches and release notes publicly
> (rather than just using emails) so you’ll see more of these in
> future. When we make patches we push the changes to upstream
> branches as well, in fact we fix on upstream first.

Kudos to ShapeBlue team!!! Many thanks for your contributions and help on 
promoting this project. I love you guys!!! 

> In our experience the 4.3.x releases are most stable and so we’re
> backporting bugfixes from 4.4/4.5/master. I’m personally going
> through a list of JIRA issues which has affect version 4.3.0 and/or
> 4.3.1 but the bugfix either does not exist or exists in a non-4.3
> branch.

> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab

> Find out more about ShapeBlue and our range of CloudStack related
> services

> IaaS Cloud Design &
> Build
> CSForge – rapid IaaS deployment
> framework
> CloudStack Consulting
> CloudStack Software
> Engineering
> CloudStack Infrastructure
> Support
> CloudStack Bootcamp Training
> Courses

> 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 L

Re: [DISCUSS] LTS Releases

[Hugo Trippaers]

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  wrote:
> 
> Hey Daan,
> 
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland  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 

Re: [DISCUSS] LTS Releases

[Daan Hoogland]

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  wrote:
> Hey Daan,
>
>> On 25-Nov-2014, at 7:26 pm, Daan Hoogland  wrote:

-- 
Daan

Re: [DISCUSS] LTS Releases

[Rohit Yadav]

Hey Daan,

> On 25-Nov-2014, at 7:26 pm, Daan Hoogland  wrote:
>
> That is worrying, Rohit. As the rest of your mail is already a vote of
> distrust, this part says we should not release 4.4.2 as it contains
> regressions.

Looks like you skimmed my email and missed the following from my previous email:
“Note: This is not to say that 4.4.x is not stable, we’re simply saying we 
recommend 4.3.x because we have a confidence of its stability and we encourage 
serious CloudStack users to use it.”

4.4.x is probably the greatest ACS feature release ever but I would still 
recommend conservative users (who consult me) to stick to 4.3.x for production 
since we know it just works with least amount of pain. The other issue is I 
know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s 
customers) want to have bugfix releases and they may not want to migrate to 
4.4.x right now since 4.5.x is about 2–3 months away.

ACS when consumed by enterprise companies has a typical lifecycle that lasts at 
least 6 months, that means someone needs to support it, therefore the idea of 
official LTS releases.

> This is a very bad signal to users and the rest of the
> community. What you are saying is (you in transitive form), 'we won't
> port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and
> not to a 4.4 version. You have the right to do so but I don't like it.

In any form I did not say anything about not helping out or not porting things. 
People who know me, know that I love to help everyone and I’m quite prompt at 
reply and resolving things. I’ve taken the task to maintain 4.3 and you’re very 
welcome to go thorough JIRA etc. to backport things that you want for 4.4 since 
you’re alone the gatekeeper of this branch.

I’m going through these bugs that have a different fix version (not 4.3.0 or 
4.3.1): https://issues.apache.org/jira/issues/?filter=12329775

Wido suggested that backporting is time consuming so as a challenge I’ve went 
through 50 issues today, I was able to understand/backport about 25 of them 
that qualified for 4.3 branch (many of them were trivial, 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f72eb945540e607ff25917922b4084187246f31a),
 about 10 of them were hard to backport so I’ve asked authors to help out. I 
think with this speed I alone should be able to go through like 300 issues 
reported on JIRA in about 10-15 days time and after than about 10-20 days of 
testing and getting the bugfix release out. Though if we all help out we can 
get more mileage.

It sucks for me personally that I’ve been emailing you privately about 
cherry-pick and asking you to pick them on 4.4 (also leaving messages on JIRA). 
I’ll continue to do that :) and meanwhile, you are very welcome to go see the 
things I picked on 4.3 and pick those applicable on 4.4.

Yours friendly and as always,

Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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

[Daan Hoogland]

On Tue, Nov 25, 2014 at 3:47 PM, Nux!  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

[Vadim Kimlaychuk]

I do prefer 4.4 as well because it has GPU sharing and we actively test it.  
Other bugs are not so important for us right now.

Vadim.

-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: Tuesday, November 25, 2014 4:48 PM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] LTS Releases

Daan,

I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does 
its job.
If I were to deploy today it would still be with 4.4. Hope this makes you feel 
better. :-)

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Cc: us...@cloudstack.apache.org
> Sent: Tuesday, 25 November, 2014 13:56:12
> Subject: Re: [DISCUSS] LTS Releases

> On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav  
> 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

[Nux!]

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" 
> To: "dev" 
> Cc: us...@cloudstack.apache.org
> Sent: Tuesday, 25 November, 2014 13:56:12
> Subject: Re: [DISCUSS] LTS Releases

> On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav  
> 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

[Nux!]

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" 
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Sent: Tuesday, 25 November, 2014 13:40:23
> Subject: Re: [DISCUSS] LTS Releases

> Hi Wido and Lucian,
> 
> There are many ways to get to a stable product including fixing coverity 
> issues,
> unit/integration tests etc. but one of those ways is to simply support 
> existing
> releases with bugfix releases because most CloudStack users just don’t care
> about git workflows, or coverity or unit/integration tests, they simply expect
> it to work and if it has bugs they expect them to be fixed.
> 
> We don’t have production usage data and feedback from users to conclude that
> 4.4.x releases are stable enough. Some of them (include our customers) have
> tried to upgrade their test prod. environments from 4.3.x to 4.4.x and have
> failed. So we decided to put backporting/testing efforts on 4.3 which we have
> confidence that it just works until a stable 4.5.x on which we have a certain
> confidence is released.
> 
> Just to put out a note here - many smart and active contributors/users may 
> know
> their way around CloudStack such as Wido/PCExtreme and Lucian, but many
> large/serious CloudStack users are slow to change and upgrading every 3-4
> months may not be an option for them. I know quite a few users who are
> operating large clouds and are still on ACS 4.2.x. This simply means they are
> not going to simply upgrade just because there is a new release with lots of
> new features. Therefore the idea of supporting those releases until we have a
> confidence of a new stable release.
> 
> Note: This is not to say that 4.4.x is not stable, we’re simply saying we
> recommend 4.3.x because we have a confidence of its stability and we encourage
> serious CloudStack users to use it.
> 
> The 4.4 branch does not contain many bugfixes which are in 4.3 and on
> master/4.5. I anticipate that 4.5.0 should be out in about 2 months time 
> around
> Jan/Feb 2015. With this anticipation and known confidence of 4.3.x in
> production at ShapeBlue we decided to support 4.3 branch until a stable 4.5.x
> branch is out.

Re: [DISCUSS] LTS Releases

[Daan Hoogland]

On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav  wrote:
> The 4.4 branch does not contain many bugfixes which are in 4.3 and on 
> master/4.5.


That is worrying, Rohit. As the rest of your mail is already a vote of
distrust, this part says we should not release 4.4.2 as it contains
regressions. This is a very bad signal to users and the rest of the
community. What you are saying is (you in transitive form), 'we won't
port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and
not to a 4.4 version. You have the right to do so but I don't like it.
Fortunately, I met people at CCCEU stating that 4.4 was working
perfectly for them. Unfortunately an incompatibility seldom is just
for- or backward. Most of the time it is two way. Will you support
transitioning from 4.4 to 4.5 as rigorously as you now discourage the
transition to 4.4? I think you will need to.

-- 
Daan

Re: [DISCUSS] LTS Releases

[Rohit Yadav]

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!  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" 
>> To: "dev" 
>> Cc: us...@cloudstack.apache.org
>> Sent: Tuesday, 25 November, 2014 11:30:53
>> Subject: [DISCUSS] LTS Releases
>
>> Hi,
>>
>> During CCCEU14 conference and over emails, I spoke with many CloudStack users
>> and I think most of us would like to have and use LTS releases. I propose 
>> that;
>>
>> - We encourage a habit to backport a bugfix to all qualifying branches 
>> whether
>> or not those branches are LTS
>> - We contribute (unit, integration) tests on LTS branches as well on other
>> qualifying branches
>> - We put correct affect version and fix version on JIRA so issues that 
>> should be
>> backported to a branch are identified
>> - We adapt the LTS release model from Fedora/Ubuntu projects. Please share
>> ideas, comments?
>> - We officially recognize a LTS release branch, say 4.3 now and everyone 
>> helps
>> to maintain it, backport bugfixes etc.
>> - Until a next latest stable release is published that we all mutually 
>> agree, we
>> keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1
>> release, we can agree to recognize 4.5 as our next LTS branch and work on it.
>>
>> Having a robust product release means we all (developers, users, sysadmins, 
>> ops
>> etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS
>> branch and releases will get us there because on a LTS release/support branch
>> we don’t do feature work at all and we only invest time to do bugfixing etc.
>>
>> ShapeBlue is already serving their customers with product patching service 
>> and
>> using our own packages hosting (http://shapeblue.com/packages) we publish
>> patches on the “main” repository for everyone. We also publish details of the
>> patch we publish on our Github wiki, such as this example;
>> https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01
>> We’ve recently started putting patches and release notes publicly (rather 
>> than
>> just using emails) so you’ll see more of these in future. When we make 
>> patches
>> we push the changes to upstream branches as well, in fact we fix on upstream
>> first.
>>
>> In our experience the 4.3.x releases are most stable and so we’re backporting
>> bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA
>> issues which has affect version 4.3.0 and/or 4.3.1 but the bugfi

Re: [DISCUSS] LTS Releases

[Nux!]

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" 
> To: "dev" 
> Cc: us...@cloudstack.apache.org
> Sent: Tuesday, 25 November, 2014 11:30:53
> Subject: [DISCUSS] LTS Releases

> Hi,
> 
> During CCCEU14 conference and over emails, I spoke with many CloudStack users
> and I think most of us would like to have and use LTS releases. I propose 
> that;
> 
> - We encourage a habit to backport a bugfix to all qualifying branches whether
> or not those branches are LTS
> - We contribute (unit, integration) tests on LTS branches as well on other
> qualifying branches
> - We put correct affect version and fix version on JIRA so issues that should 
> be
> backported to a branch are identified
> - We adapt the LTS release model from Fedora/Ubuntu projects. Please share
> ideas, comments?
> - We officially recognize a LTS release branch, say 4.3 now and everyone helps
> to maintain it, backport bugfixes etc.
> - Until a next latest stable release is published that we all mutually agree, 
> we
> keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1
> release, we can agree to recognize 4.5 as our next LTS branch and work on it.
> 
> Having a robust product release means we all (developers, users, sysadmins, 
> ops
> etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS
> branch and releases will get us there because on a LTS release/support branch
> we don’t do feature work at all and we only invest time to do bugfixing etc.
> 
> ShapeBlue is already serving their customers with product patching service and
> using our own packages hosting (http://shapeblue.com/packages) we publish
> patches on the “main” repository for everyone. We also publish details of the
> patch we publish on our Github wiki, such as this example;
> https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01
> We’ve recently started putting patches and release notes publicly (rather than
> just using emails) so you’ll see more of these in future. When we make patches
> we push the changes to upstream branches as well, in fact we fix on upstream
> first.
> 
> In our experience the 4.3.x releases are most stable and so we’re backporting
> bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA
> issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does
> not exist or exists in a non-4.3 branch.
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & 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

[Wido den Hollander]

Hi,

On 11/25/2014 12:30 PM, Rohit Yadav wrote:
> Hi,
> 
> During CCCEU14 conference and over emails, I spoke with many CloudStack users 
> and I think most of us would like to have and use LTS releases. I propose 
> that;
> 
> - We encourage a habit to backport a bugfix to all qualifying branches 
> whether or not those branches are LTS
> - We contribute (unit, integration) tests on LTS branches as well on other 
> qualifying branches
> - We put correct affect version and fix version on JIRA so issues that should 
> be backported to a branch are identified
> - We adapt the LTS release model from Fedora/Ubuntu projects. Please share 
> ideas, comments?
> - We officially recognize a LTS release branch, say 4.3 now and everyone 
> helps to maintain it, backport bugfixes etc.
> - Until a next latest stable release is published that we all mutually agree, 
> we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 
> release, we can agree to recognize 4.5 as our next LTS branch and work on it.
> 
> Having a robust product release means we all (developers, users, sysadmins, 
> ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a 
> LTS branch and releases will get us there because on a LTS release/support 
> branch we don’t do feature work at all and we only invest time to do 
> bugfixing etc.
> 
> ShapeBlue is already serving their customers with product patching service 
> and using our own packages hosting (http://shapeblue.com/packages) we publish 
> patches on the “main” repository for everyone. We also publish details of the 
> patch we publish on our Github wiki, such as this example;
> https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01
> We’ve recently started putting patches and release notes publicly (rather 
> than just using emails) so you’ll see more of these in future. When we make 
> patches we push the changes to upstream branches as well, in fact we fix on 
> upstream first.
> 
> In our experience the 4.3.x releases are most stable and so we’re backporting 
> bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA 
> issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does 
> not exist or exists in a non-4.3 branch.
> 

I'm not against it at all, I think that a lot of end-users would really
want this.

But aren't we a bit to soon? I agree that 4.3 is a good version which is
out there and 4.4.2 seems to be as well, but where do we make the decision?

I think that we should have master more stable before we can do this.

Backporting things from master to 4.3 is already a time consuming job
due to the big differences between the branches.

At PCextreme we run on 4.3 with our own homebrew version where we got
some patches from master to 4.3, but that is already taking a lot of time.

Wido

> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> 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.
> 

[DISCUSS] LTS Releases

[Rohit Yadav]

Hi,

During CCCEU14 conference and over emails, I spoke with many CloudStack users 
and I think most of us would like to have and use LTS releases. I propose that;

- We encourage a habit to backport a bugfix to all qualifying branches whether 
or not those branches are LTS
- We contribute (unit, integration) tests on LTS branches as well on other 
qualifying branches
- We put correct affect version and fix version on JIRA so issues that should 
be backported to a branch are identified
- We adapt the LTS release model from Fedora/Ubuntu projects. Please share 
ideas, comments?
- We officially recognize a LTS release branch, say 4.3 now and everyone helps 
to maintain it, backport bugfixes etc.
- Until a next latest stable release is published that we all mutually agree, 
we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 
release, we can agree to recognize 4.5 as our next LTS branch and work on it.

Having a robust product release means we all (developers, users, sysadmins, ops 
etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS 
branch and releases will get us there because on a LTS release/support branch 
we don’t do feature work at all and we only invest time to do bugfixing etc.

ShapeBlue is already serving their customers with product patching service and 
using our own packages hosting (http://shapeblue.com/packages) we publish 
patches on the “main” repository for everyone. We also publish details of the 
patch we publish on our Github wiki, such as this example;
https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01
We’ve recently started putting patches and release notes publicly (rather than 
just using emails) so you’ll see more of these in future. When we make patches 
we push the changes to upstream branches as well, in fact we fix on upstream 
first.

In our experience the 4.3.x releases are most stable and so we’re backporting 
bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA 
issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does 
not exist or exists in a non-4.3 branch.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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.