LTS release or not

[Rene Moser <ma...@renemoser.net>]

Hi

I recently started a discussion about the current release process. You
may have noticed that CloudStack had a few releases in the last 2 months.

My concerns were that many CloudStack users will be confused about these
many releases (which one to take? Are fixes backported? How long will it
receive fixes? Do I have to upgrade?).

We leads me to the question: Does CloudStack need an LTS version? To me
it would make sense in many ways:

* Users in restrictive cloud environments can choose LTS for getting
backwards compatible bug fixes only.

* Users in agile cloud environments can choose latest stable and getting
new features fast.

* CloudStack developers must only maintain the latest stable (mainline)
and the LTS version.

* CloudStack developers and mainline users can accept, that mainline may
break environments but will receive fast forward fixes.

To me this would make a lot of sense. I am actually thinking about
maintaining 4.5 as a LTS by myself.

Any thoughts? +1/-1?

Regards
René

Re: LTS release or not

[Sebastien Goasguen <ru...@gmail.com>]

About LTS.

Here are some of the Mesos releases:

+## Releases ##
+
+ * Apache Mesos 0.23.1 (2015-09-21)
+ * Apache Mesos 0.22.2 (2015-09-23)
+ * Apache Mesos 0.21.2 (2015-09-24)
+ * Apache Mesos 0.25.0 (2015-10-09)
+ * Apache Mesos 0.26.0 (2015-12-10)

quite frequent.

Anyone cares to check their policies and CI…?


> On Jan 12, 2016, at 1:11 AM, ilya <il...@gmail.com> wrote:
> 
> Hi Rene
> 
> 
> In short BIG +1, for longer summary, please read below....
> 
> 
> PS: For LTS - you mean "Long Term Support" i assume.
> 
> We would be interested in seeing the support of 4.5 longer as well, as
> we are happy with what we got so far and dont have a burning need to
> upgrade yet.
> 
> Upgrade would also require serious testing across the board, so LTS
> release can buy us more time.
> 
> This is my opinion, Marcus would probably have a different opinion on this.
> 
> ---------
> 
> Side note:
> I had a somewhat similar endeavor few years back that attempted to solve
> this challenge. Though it was not just around "Long Term Support", but
> geared more towards "I need latest bug fix and feature now, I dont have
> 8+ months to wait".
> 
> I called the project CloudSand.
> 
> Back then, i was mostly focusing on ACS + VMware Integration, as the
> code existed in master branch but not in 4.1. Also did a small talk
> about it back in 2013 @ CCC in SF Bay area.
> 
> https://www.youtube.com/watch?v=4wuEPoxVlBM
> 
> You can see it under www.cloudsand.com  - though now no longer
> maintained due to $dayjob$ restrictions (its complicated).
> 
> Either way, i'm in strong support of this initiative. I'm thinking just
> about anyone with fairly sized infrastructure - might do the same, why
> not merge the efforts?
> 
> Things to consider (this is strictly my opinion):
> 1) Pull/merge requests must be reviewed with scrutiny, we dont want LTS
> to be a test bed, but rather a stable build
> 2) Database changes should be avoided unless someone wants to maintain
> upgrade path, i just think it would be easier to just not pull commits
> that require DB change
> 3) End user should be able to upgrade to latest official ACS version
> without any issues or switch between - there should be no lock in..
> 
> I'd like to help with this effort, but don't know how much time i can
> dedicate to this effort.
> 
> Regards,
> ilya
> 
> 
> 
> On 1/9/16 2:51 PM, Rene Moser wrote:
>> Hi
>> 
>> I recently started a discussion about the current release process. You
>> may have noticed that CloudStack had a few releases in the last 2 months.
>> 
>> My concerns were that many CloudStack users will be confused about these
>> many releases (which one to take? Are fixes backported? How long will it
>> receive fixes? Do I have to upgrade?).
>> 
>> We leads me to the question: Does CloudStack need an LTS version? To me
>> it would make sense in many ways:
>> 
>> * Users in restrictive cloud environments can choose LTS for getting
>> backwards compatible bug fixes only.
>> 
>> * Users in agile cloud environments can choose latest stable and getting
>> new features fast.
>> 
>> * CloudStack developers must only maintain the latest stable (mainline)
>> and the LTS version.
>> 
>> * CloudStack developers and mainline users can accept, that mainline may
>> break environments but will receive fast forward fixes.
>> 
>> To me this would make a lot of sense. I am actually thinking about
>> maintaining 4.5 as a LTS by myself.
>> 
>> Any thoughts? +1/-1?
>> 
>> Regards
>> René
>> 

Re: LTS release or not

[ilya <il...@gmail.com>]

Hi Rene


In short BIG +1, for longer summary, please read below....


PS: For LTS - you mean "Long Term Support" i assume.

We would be interested in seeing the support of 4.5 longer as well, as
we are happy with what we got so far and dont have a burning need to
upgrade yet.

Upgrade would also require serious testing across the board, so LTS
release can buy us more time.

This is my opinion, Marcus would probably have a different opinion on this.

---------

Side note:
I had a somewhat similar endeavor few years back that attempted to solve
this challenge. Though it was not just around "Long Term Support", but
geared more towards "I need latest bug fix and feature now, I dont have
8+ months to wait".

I called the project CloudSand.

Back then, i was mostly focusing on ACS + VMware Integration, as the
code existed in master branch but not in 4.1. Also did a small talk
about it back in 2013 @ CCC in SF Bay area.

https://www.youtube.com/watch?v=4wuEPoxVlBM

You can see it under www.cloudsand.com  - though now no longer
maintained due to $dayjob$ restrictions (its complicated).

Either way, i'm in strong support of this initiative. I'm thinking just
about anyone with fairly sized infrastructure - might do the same, why
not merge the efforts?

Things to consider (this is strictly my opinion):
1) Pull/merge requests must be reviewed with scrutiny, we dont want LTS
to be a test bed, but rather a stable build
2) Database changes should be avoided unless someone wants to maintain
upgrade path, i just think it would be easier to just not pull commits
that require DB change
3) End user should be able to upgrade to latest official ACS version
without any issues or switch between - there should be no lock in..

I'd like to help with this effort, but don't know how much time i can
dedicate to this effort.

Regards,
ilya



On 1/9/16 2:51 PM, Rene Moser wrote:
> Hi
> 
> I recently started a discussion about the current release process. You
> may have noticed that CloudStack had a few releases in the last 2 months.
> 
> My concerns were that many CloudStack users will be confused about these
> many releases (which one to take? Are fixes backported? How long will it
> receive fixes? Do I have to upgrade?).
> 
> We leads me to the question: Does CloudStack need an LTS version? To me
> it would make sense in many ways:
> 
> * Users in restrictive cloud environments can choose LTS for getting
> backwards compatible bug fixes only.
> 
> * Users in agile cloud environments can choose latest stable and getting
> new features fast.
> 
> * CloudStack developers must only maintain the latest stable (mainline)
> and the LTS version.
> 
> * CloudStack developers and mainline users can accept, that mainline may
> break environments but will receive fast forward fixes.
> 
> To me this would make a lot of sense. I am actually thinking about
> maintaining 4.5 as a LTS by myself.
> 
> Any thoughts? +1/-1?
> 
> Regards
> René
> 

Re: Summary: -1 LTS

[Frank Louwers <fr...@openminds.be>]

All,

I am +1 on TLS: We have a custom branch of CloudStack, with a few custom patches. Some of which make sense for everyone, and we’ve committed them back, or plan to do so, but most of them only work for our specific case, or “cur corners” by dropping features we don’t need.

An LTS branch would allow us to keep our patches “good” against LTS. Our current tree is based on 4.5. I’d need to perform some manual patchwork to make them apply against 4.6, let alone 4.7. Having an LTS would mean I’d only have to do this every few years...

I know this might sound selfish. But I assume I am not the only one in this case…

Regards,

Frank


> On 11 Jan 2016, at 16:18, Daan Hoogland <da...@gmail.com> wrote:
> 
> (rant alert) I have been stating this in the discuss thread and I don't
> agree with your conclusion; with our new workflow any release is a LTS as
> long as we maintain the discipline of allowing only bugfixes on the release
> they first appeared in (or 4.6 as a start point) If we maintain that
> discipline during review any release henceforth is an LTS. Of course people
> can pay others to backport outside the Apache CloudStack project if they
> want, as well. but the notion that we don't have an LTS at the moment
> hurts. (end of rant)
> 
> On Mon, Jan 11, 2016 at 3:25 PM, Rene Moser <ma...@renemoser.net> wrote:
> 
>> LTS by the community is not an option for now:
>> 
>> Most of the threads/users/devs had concerns or are skeptical how it can
>> be done in practice.
>> 
>> As we recently changed the release process, it seems to "early" to
>> change it again or add new processes to it.
>> 
>> I still think CloudStack need some kind of LTS to serve business needs
>> but unsure if _we_ as community should do it.
>> 
>> Thanks for participating.
>> 
>> Regards
>> René
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Daan

Re: Summary: -1 LTS

[Daan Hoogland <da...@gmail.com>]

(rant alert) I have been stating this in the discuss thread and I don't
agree with your conclusion; with our new workflow any release is a LTS as
long as we maintain the discipline of allowing only bugfixes on the release
they first appeared in (or 4.6 as a start point) If we maintain that
discipline during review any release henceforth is an LTS. Of course people
can pay others to backport outside the Apache CloudStack project if they
want, as well. but the notion that we don't have an LTS at the moment
hurts. (end of rant)

On Mon, Jan 11, 2016 at 3:25 PM, Rene Moser <ma...@renemoser.net> wrote:

> LTS by the community is not an option for now:
>
> Most of the threads/users/devs had concerns or are skeptical how it can
> be done in practice.
>
> As we recently changed the release process, it seems to "early" to
> change it again or add new processes to it.
>
> I still think CloudStack need some kind of LTS to serve business needs
> but unsure if _we_ as community should do it.
>
> Thanks for participating.
>
> Regards
> René
>
>
>
>


-- 
Daan

Re: Summary: -1 LTS

[Daan Hoogland <da...@gmail.com>]

(rant alert) I have been stating this in the discuss thread and I don't
agree with your conclusion; with our new workflow any release is a LTS as
long as we maintain the discipline of allowing only bugfixes on the release
they first appeared in (or 4.6 as a start point) If we maintain that
discipline during review any release henceforth is an LTS. Of course people
can pay others to backport outside the Apache CloudStack project if they
want, as well. but the notion that we don't have an LTS at the moment
hurts. (end of rant)

On Mon, Jan 11, 2016 at 3:25 PM, Rene Moser <ma...@renemoser.net> wrote:

> LTS by the community is not an option for now:
>
> Most of the threads/users/devs had concerns or are skeptical how it can
> be done in practice.
>
> As we recently changed the release process, it seems to "early" to
> change it again or add new processes to it.
>
> I still think CloudStack need some kind of LTS to serve business needs
> but unsure if _we_ as community should do it.
>
> Thanks for participating.
>
> Regards
> René
>
>
>
>


-- 
Daan

Summary: -1 LTS

[Rene Moser <ma...@renemoser.net>]

LTS by the community is not an option for now:

Most of the threads/users/devs had concerns or are skeptical how it can
be done in practice.

As we recently changed the release process, it seems to "early" to
change it again or add new processes to it.

I still think CloudStack need some kind of LTS to serve business needs
but unsure if _we_ as community should do it.

Thanks for participating.

Regards
René

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

Daan

Have not yet decided which version, but fixes will be backported into
LTS not the other way around.

But I see what you mean. The code base may have much diverted before 4.7
right?

It is not really a problem. It only means more work (argh...). Sooner or
later this will happen for every release we choose.

I would like to use 4.5 for several reasons, one obvious is, that we
know that it is in production on several clouds, including us.


On 01/10/2016 12:40 PM, Daan Hoogland wrote:
> Rene, I would advice to support 4.7 as LTS. It adheres to the new
> development/release process unlike 4.5 and any bugfixes there can
> automatically be merged forward to newer releases to reduce the chance of
> regression.
> 
> I am in favour of the general concept.
> 
> On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro <rubens.malheiro@gmail.com
>> wrote:
> 
>> +1
>> Em 9 de jan de 2016 8:55 PM, "Rene Moser" <ma...@renemoser.net> escreveu:
>>
>>> Hi
>>>
>>> I recently started a discussion about the current release process. You
>>> may have noticed that CloudStack had a few releases in the last 2 months.
>>>
>>> My concerns were that many CloudStack users will be confused about these
>>> many releases (which one to take? Are fixes backported? How long will it
>>> receive fixes? Do I have to upgrade?).
>>>
>>> We leads me to the question: Does CloudStack need an LTS version? To me
>>> it would make sense in many ways:
>>>
>>> * Users in restrictive cloud environments can choose LTS for getting
>>> backwards compatible bug fixes only.
>>>
>>> * Users in agile cloud environments can choose latest stable and getting
>>> new features fast.
>>>
>>> * CloudStack developers must only maintain the latest stable (mainline)
>>> and the LTS version.
>>>
>>> * CloudStack developers and mainline users can accept, that mainline may
>>> break environments but will receive fast forward fixes.
>>>
>>> To me this would make a lot of sense. I am actually thinking about
>>> maintaining 4.5 as a LTS by myself.
>>>
>>> Any thoughts? +1/-1?
>>>
>>> Regards
>>> René
>>>
>>
> 
> 
> 

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

Daan

Have not yet decided which version, but fixes will be backported into
LTS not the other way around.

But I see what you mean. The code base may have much diverted before 4.7
right?

It is not really a problem. It only means more work (argh...). Sooner or
later this will happen for every release we choose.

I would like to use 4.5 for several reasons, one obvious is, that we
know that it is in production on several clouds, including us.


On 01/10/2016 12:40 PM, Daan Hoogland wrote:
> Rene, I would advice to support 4.7 as LTS. It adheres to the new
> development/release process unlike 4.5 and any bugfixes there can
> automatically be merged forward to newer releases to reduce the chance of
> regression.
> 
> I am in favour of the general concept.
> 
> On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro <rubens.malheiro@gmail.com
>> wrote:
> 
>> +1
>> Em 9 de jan de 2016 8:55 PM, "Rene Moser" <ma...@renemoser.net> escreveu:
>>
>>> Hi
>>>
>>> I recently started a discussion about the current release process. You
>>> may have noticed that CloudStack had a few releases in the last 2 months.
>>>
>>> My concerns were that many CloudStack users will be confused about these
>>> many releases (which one to take? Are fixes backported? How long will it
>>> receive fixes? Do I have to upgrade?).
>>>
>>> We leads me to the question: Does CloudStack need an LTS version? To me
>>> it would make sense in many ways:
>>>
>>> * Users in restrictive cloud environments can choose LTS for getting
>>> backwards compatible bug fixes only.
>>>
>>> * Users in agile cloud environments can choose latest stable and getting
>>> new features fast.
>>>
>>> * CloudStack developers must only maintain the latest stable (mainline)
>>> and the LTS version.
>>>
>>> * CloudStack developers and mainline users can accept, that mainline may
>>> break environments but will receive fast forward fixes.
>>>
>>> To me this would make a lot of sense. I am actually thinking about
>>> maintaining 4.5 as a LTS by myself.
>>>
>>> Any thoughts? +1/-1?
>>>
>>> Regards
>>> René
>>>
>>
> 
> 
> 

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

Rene, I would advice to support 4.7 as LTS. It adheres to the new
development/release process unlike 4.5 and any bugfixes there can
automatically be merged forward to newer releases to reduce the chance of
regression.

I am in favour of the general concept.

On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro <rubens.malheiro@gmail.com
> wrote:

> +1
> Em 9 de jan de 2016 8:55 PM, "Rene Moser" <ma...@renemoser.net> escreveu:
>
> > Hi
> >
> > I recently started a discussion about the current release process. You
> > may have noticed that CloudStack had a few releases in the last 2 months.
> >
> > My concerns were that many CloudStack users will be confused about these
> > many releases (which one to take? Are fixes backported? How long will it
> > receive fixes? Do I have to upgrade?).
> >
> > We leads me to the question: Does CloudStack need an LTS version? To me
> > it would make sense in many ways:
> >
> > * Users in restrictive cloud environments can choose LTS for getting
> > backwards compatible bug fixes only.
> >
> > * Users in agile cloud environments can choose latest stable and getting
> > new features fast.
> >
> > * CloudStack developers must only maintain the latest stable (mainline)
> > and the LTS version.
> >
> > * CloudStack developers and mainline users can accept, that mainline may
> > break environments but will receive fast forward fixes.
> >
> > To me this would make a lot of sense. I am actually thinking about
> > maintaining 4.5 as a LTS by myself.
> >
> > Any thoughts? +1/-1?
> >
> > Regards
> > René
> >
>



-- 
Daan

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

Rene, I would advice to support 4.7 as LTS. It adheres to the new
development/release process unlike 4.5 and any bugfixes there can
automatically be merged forward to newer releases to reduce the chance of
regression.

I am in favour of the general concept.

On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro <rubens.malheiro@gmail.com
> wrote:

> +1
> Em 9 de jan de 2016 8:55 PM, "Rene Moser" <ma...@renemoser.net> escreveu:
>
> > Hi
> >
> > I recently started a discussion about the current release process. You
> > may have noticed that CloudStack had a few releases in the last 2 months.
> >
> > My concerns were that many CloudStack users will be confused about these
> > many releases (which one to take? Are fixes backported? How long will it
> > receive fixes? Do I have to upgrade?).
> >
> > We leads me to the question: Does CloudStack need an LTS version? To me
> > it would make sense in many ways:
> >
> > * Users in restrictive cloud environments can choose LTS for getting
> > backwards compatible bug fixes only.
> >
> > * Users in agile cloud environments can choose latest stable and getting
> > new features fast.
> >
> > * CloudStack developers must only maintain the latest stable (mainline)
> > and the LTS version.
> >
> > * CloudStack developers and mainline users can accept, that mainline may
> > break environments but will receive fast forward fixes.
> >
> > To me this would make a lot of sense. I am actually thinking about
> > maintaining 4.5 as a LTS by myself.
> >
> > Any thoughts? +1/-1?
> >
> > Regards
> > René
> >
>



-- 
Daan

Re: LTS release or not

[Rubens Malheiro <ru...@gmail.com>]

+1
Em 9 de jan de 2016 8:55 PM, "Rene Moser" <ma...@renemoser.net> escreveu:

> Hi
>
> I recently started a discussion about the current release process. You
> may have noticed that CloudStack had a few releases in the last 2 months.
>
> My concerns were that many CloudStack users will be confused about these
> many releases (which one to take? Are fixes backported? How long will it
> receive fixes? Do I have to upgrade?).
>
> We leads me to the question: Does CloudStack need an LTS version? To me
> it would make sense in many ways:
>
> * Users in restrictive cloud environments can choose LTS for getting
> backwards compatible bug fixes only.
>
> * Users in agile cloud environments can choose latest stable and getting
> new features fast.
>
> * CloudStack developers must only maintain the latest stable (mainline)
> and the LTS version.
>
> * CloudStack developers and mainline users can accept, that mainline may
> break environments but will receive fast forward fixes.
>
> To me this would make a lot of sense. I am actually thinking about
> maintaining 4.5 as a LTS by myself.
>
> Any thoughts? +1/-1?
>
> Regards
> René
>

Re: LTS release or not

[ilya <il...@gmail.com>]

There are good points for and against LTS. I do have specific use case
that LTS solves, but in my opinion the scope of LTS would need to be
revised.

Why LTS is good idea?
If you have environment with thousands of servers, upgrading from 4.5 to
4.7 and beyond would be rather risky. There are instances when specific
issues will surface only on very large scale. I've seen it many times,
where my small QA environments would work just fine, but once i go into
a much larger environment with at least 300+ hypervisors - things dont
work as well. Moreover, it may take some time for these issues to surface.

LTS buys us time to properly test, plan, migrate and yet be up-to-date.

If we are open to revising the scope of LTS, it may be more manageable.

Things to consider with LTS to include include:

1) Applicable bug and security fixes
2) Low impact features that don't have dependencies on newer code (i.e.
strongswan VPN would *not* qualify)
3) Features that don't require DB schema change (if such comes thru, it
needs to be heavily scrutinized and commiter needs to provide and test
the upgrade path to next release)

If i'm not mistaken, kernel and most of linux open source packages are
similarly maintained (though in many cases by distribution vendors like
redhat/debian).

Regards
ilya



On 1/10/16 2:46 PM, Erik Weber wrote:
> On Sun, Jan 10, 2016 at 10:27 PM, Rene Moser <ma...@renemoser.net> wrote:
> 
>>
>> On 01/10/2016 10:07 PM, Wido den Hollander wrote:
>>> Ok, understood. However, it will be up to users on their own to pick
>>> this LTS maintainment up.
>>
>> It would be up to the devs making fixes small (so no squashing for
>> fixes) and notify the one maintaining the LTS version if they feel the
>> fix is that important to be in LTS. Wouldn't be that hard work.
>>
>>
> What if the fix is part of a refactorization or a new feature?
> Providing a LTS is not 'easy as pie' with a product like CloudStack where a
> lot of code changes over time.
> 
> For instance, /if/ the strongswan feature is merged to 4.8, how to you
> handle /ANY/ VPN fixes in 4.5 since they don't even use the same software?
> And the whole VR process was refactored in 4.6 -- meaning you won't be
> using the same scripts, or even the same language.
> 
> Even if a bugfix is included in master and tested, it is impossible to say
> how it will react with an older/different solution.
> 
> The same can be said for library updates etc.
> 
> Don't get me wrong, I'm not opposing a LTS version -- actually I would
> rather like to have one. I just want to be clear about the fact that it
> won't be always be easy, and not all fixes might be possible to backport --
> depending on how strict you'll be with 3rd party stuff.
> 
> 
> 
>>> That means testing, releasing, testing, backporting, testing, releasing.
>>>
>>> Certain users will focus on getting new releases out and others on doing
>>> LTS work.
>>
>> The process of backporting is not defined yet, but I would like to adopt
>> the Linux kernel long term policy:
>>
>> * Fix must be already in mainline
>>
> 
> See above, the fix might not be necessary in master/mainline.
> 
> 
>> * Fix must be important.
>>
> 
> Who defines what 'important' is?
> 
> 
>> * Fix must be obvious and small.
>>
>> Which means, we only fix stuff in LTS which is already fixed in
>> mainline. Important stuff only.
>>
>> We can even define, the mainline version must be released with the fix,
>> before getting into LTS. So even the LTS releases would be behind the
>> mainline releases and the fix has been tested in mainline.
>>
> 
> On a last note, doing LTS -- atleast in my opinion -- requires commitment.
> Anything called LTS is usually getting a lot of user focus/traction and
> have to be rock solid and maintained.
> 

Re: LTS release or not

[John Burwell <jo...@shapeblue.com>]

All,

It seems that there is general agreement on the following:

1. There are users that need periodic releases that only focus on stability to minimize change and deployment risk (i.e. LTS releases)
2. There are users that need frequent releases that deliver new capabilities (i.e. monthly releases)
3. These two release types are not mutually exclusive and can be developed in a complementary manner
4. Assuming community has the resources available, we would like to deliver both monthly and LTS releases

For a sometime, ShapeBlue have been considering a proposal to supplement the monthly release cycle with an LTS release cycle. We believe that offering both monthly and LTS releases will make CloudStack more attractive to new users, as well as, addressing the requirements of all current CloudStack users. I expect to publish an LTS proposal within the next day or so that includes most, if not all, of the points discussed on this thread. Hopefully, we will quickly gain consensus on an LTS release cycle, and begin doing the work necessary to deliver high quality LTS releases.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:      john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:>     |      w:      www.shapeblue.com<http://www.shapeblue.com>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image5c2903.png@05139e21.40b48007]


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




On Jan 12, 2016, at 2:43 PM, Nux! <nu...@li.nux.ro> wrote:
>
> Remi,
>
> Yes, that, that's great then, thanks.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> ----- Original Message -----
>> From: "Remi Bergsma" <RB...@schubergphilis.com>
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 12 January, 2016 19:04:55
>> Subject: Re: LTS release or not
>
>> Hi Lucian,
>>
>> Are you referring to the forward merging?
>> That has been scripted:
>> https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge
>>
>> There may be conflicts at some point, but that also happens with cherry-picking.
>>
>> If you mean something else I probably missed your point, sorry.
>>
>> Regards,
>> Remi
>>
>>
>>
>>
>> On 12/01/16 17:17, "Nux!" <nu...@li.nux.ro> wrote:
>>
>>> Guys, I am not a coder to appreciate how sustainable this would be.
>>>
>>> Who around here with actual java skills thinks this is achievable in a
>>> reasonable way? Cause if it's not we're just wasting time.
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> ----- Original Message -----
>>>> From: "Remi Bergsma" <RB...@schubergphilis.com>
>>>> To: dev@cloudstack.apache.org
>>>> Sent: Tuesday, 12 January, 2016 15:36:52
>>>> Subject: Re: LTS release or not
>>>
>>>> Hi,
>>>>
>>>> The method Daan describes can be done from 4.6 and on. It’s about merging a PR
>>>> with a fix, and forward merging it. Not about actually releasing immediately.
>>>>
>>>> If the bug has always been there, one would merge to 4.6, merge forward to newer
>>>> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
>>>>
>>>> Regards,
>>>> Remi
>>>>
>>>>
>>>>
>>>> On 12/01/16 15:55, "Ron Wheeler" <rw...@artifact-software.com> wrote:
>>>>
>>>>> Depending on how far back the problem originated, this may not be
>>>>> practical.
>>>>> The code might have been massaged many times or code may have been
>>>>> written that depends on the buggy behaviour.
>>>>>
>>>>> If the bug "was always there" but no one had figured out the exploit, it
>>>>> might not be possible to identify any particular commit at all.
>>>>>
>>>>> Would your solution trigger a whole bunch of new releases - 4.4.x,
>>>>> 4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>>>> and noted while we wait for enough to accumulate to trigger a new
>>>>> release? Who would want to work on 4.4.x release?
>>>>>
>>>>> The amount of testing required to support all that backporting would
>>>>> certainly deter people from fixing old bugs!
>>>>>
>>>>> No code is bug free so I am not sure how bad it is to say that a bug
>>>>> will only be fixed in the LTS and current release.
>>>>>
>>>>> System administrators can then decide if the bug is worth an update to
>>>>> the fixed version or should be fixed on the release that they currently
>>>>> run, causing a local fork that they will deal with during their next
>>>>> upgrade cycle.
>>>>>
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>>>>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>>>>>> commit it was introduced in and thenn be merged forward. It can then be
>>>>>> merged into any branch that contains the offending commit and there is no
>>>>>> longer any difference between LTS or anything else. Am I speaking
>>>>>> Kardeshian? I am really surprised no one in this list sees source code and
>>>>>> release management this way.
>>>>>>
>>>>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>>>>>>> wrote:
>>>>>>> There may have to be some rules about patches such as
>>>>>>> "You may not apply any bug fix to a minor release that will break the
>>>>>>> upgrade path."
>>>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>>>>>> If a user absolutely needs a fix that breaks this, then it is their
>>>>>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>>>>>> stable branch.
>>>>>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>>>>>> upgraded.
>>>>>>>
>>>>>>> Any user that applies the offending patch to 4.6.2 should know that they
>>>>>>> have created their own misery and will have to work out the upgrade at some
>>>>>>> point or continue their private fork forever.
>>>>>>>
>>>>>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>>>>>> 4.8.0 and later".
>>>>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>>>>>> No piece of software is bug-free so we are really discussing what happens
>>>>>>> once a bug is found and a fix is available.
>>>>>>> 4.6.5 will run exactly like it did before the bug was found.
>>>>>>>
>>>>>>> Bugs that will cause update issues will trigger a new major release.
>>>>>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>>>>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>>>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>>>>>
>>>>>>>
>>>>>>> My 2 cents!
>>>>>>> Ron
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>>>>>
>>>>>>>> Hi Remi
>>>>>>>>
>>>>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>>>>>
>>>>>>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>>>>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>>>>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>>>>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>>>>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>>>>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>>>>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>>>>>>> there yet.
>>>>>>>>>
>>>>>>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>>>>>>> for LTS. This would work right?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> René
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Ron Wheeler
>>>>>>> President
>>>>>>> Artifact Software Inc
>>>>>>> email: rwheeler@artifact-software.com
>>>>>>> skype: ronaldmwheeler
>>>>>>> phone: 866-970-2435, ext 102
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102

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

Re: LTS release or not

[Nux! <nu...@li.nux.ro>]

Remi,

Yes, that, that's great then, thanks.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Remi Bergsma" <RB...@schubergphilis.com>
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 12 January, 2016 19:04:55
> Subject: Re: LTS release or not

> Hi Lucian,
> 
> Are you referring to the forward merging?
> That has been scripted:
> https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge
> 
> There may be conflicts at some point, but that also happens with cherry-picking.
> 
> If you mean something else I probably missed your point, sorry.
> 
> Regards,
> Remi
> 
> 
> 
> 
> On 12/01/16 17:17, "Nux!" <nu...@li.nux.ro> wrote:
> 
>>Guys, I am not a coder to appreciate how sustainable this would be.
>>
>>Who around here with actual java skills thinks this is achievable in a
>>reasonable way? Cause if it's not we're just wasting time.
>>
>>Lucian
>>
>>--
>>Sent from the Delta quadrant using Borg technology!
>>
>>Nux!
>>www.nux.ro
>>
>>----- Original Message -----
>>> From: "Remi Bergsma" <RB...@schubergphilis.com>
>>> To: dev@cloudstack.apache.org
>>> Sent: Tuesday, 12 January, 2016 15:36:52
>>> Subject: Re: LTS release or not
>>
>>> Hi,
>>> 
>>> The method Daan describes can be done from 4.6 and on. It’s about merging a PR
>>> with a fix, and forward merging it. Not about actually releasing immediately.
>>> 
>>> If the bug has always been there, one would merge to 4.6, merge forward to newer
>>> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
>>> 
>>> Regards,
>>> Remi
>>> 
>>> 
>>> 
>>> On 12/01/16 15:55, "Ron Wheeler" <rw...@artifact-software.com> wrote:
>>> 
>>>>Depending on how far back the problem originated, this may not be
>>>>practical.
>>>>The code might have been massaged many times or code may have been
>>>>written that depends on the buggy behaviour.
>>>>
>>>>If the bug "was always there" but no one had figured out the exploit, it
>>>>might not be possible to identify any particular commit at all.
>>>>
>>>>Would your solution trigger a whole bunch of new releases - 4.4.x,
>>>>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>>>and noted while we wait for enough to accumulate to trigger a new
>>>>release? Who would want to work on 4.4.x release?
>>>>
>>>>The amount of testing required to support all that backporting would
>>>>certainly deter people from fixing old bugs!
>>>>
>>>>No code is bug free so I am not sure how bad it is to say that a bug
>>>>will only be fixed in the LTS and current release.
>>>>
>>>>System administrators can then decide if the bug is worth an update to
>>>>the fixed version or should be fixed on the release that they currently
>>>>run,  causing a local fork that they will deal with during their next
>>>>upgrade cycle.
>>>>
>>>>
>>>>Ron
>>>>
>>>>
>>>>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>>>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>>>>> commit it was introduced in and thenn be merged forward. It can then be
>>>>> merged into any branch that contains the offending commit and there is no
>>>>> longer any difference between LTS or anything else. Am I speaking
>>>>> Kardeshian? I am really surprised no one in this list sees source code and
>>>>> release management this way.
>>>>>
>>>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>>>>>> wrote:
>>>>>> There may have to be some rules about patches such as
>>>>>> "You may not apply any bug fix to a minor release that will break the
>>>>>> upgrade path."
>>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>>>>> If a user absolutely needs a fix that breaks this, then it is their
>>>>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>>>>> stable branch.
>>>>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>>>>> upgraded.
>>>>>>
>>>>>> Any user that applies the offending patch to 4.6.2 should know that they
>>>>>> have created their own misery and will have to work out the upgrade at some
>>>>>> point or continue their private fork forever.
>>>>>>
>>>>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>>>>> 4.8.0 and later".
>>>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>>>>> No piece of software is bug-free so we are really discussing what happens
>>>>>> once a bug is found and a fix is available.
>>>>>> 4.6.5 will run exactly like it did before the bug was found.
>>>>>>
>>>>>> Bugs that will cause update issues will trigger a new major release.
>>>>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>>>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>>>>
>>>>>>
>>>>>> My 2 cents!
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>>>>
>>>>>>> Hi Remi
>>>>>>>
>>>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>>>>
>>>>>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>>>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>>>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>>>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>>>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>>>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>>>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>>>>>> there yet.
>>>>>>>>
>>>>>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>>>>>> for LTS. This would work right?
>>>>>>>
>>>>>>> Regards
>>>>>>> René
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Ron Wheeler
>>>>>> President
>>>>>> Artifact Software Inc
>>>>>> email: rwheeler@artifact-software.com
>>>>>> skype: ronaldmwheeler
>>>>>> phone: 866-970-2435, ext 102
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>--
>>>>Ron Wheeler
>>>>President
>>>>Artifact Software Inc
>>>>email: rwheeler@artifact-software.com
>>>>skype: ronaldmwheeler
> >>>phone: 866-970-2435, ext 102

Re: LTS release or not

[Remi Bergsma <RB...@schubergphilis.com>]

Hi Lucian,

Are you referring to the forward merging?
That has been scripted: https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge

There may be conflicts at some point, but that also happens with cherry-picking.

If you mean something else I probably missed your point, sorry.

Regards,
Remi




On 12/01/16 17:17, "Nux!" <nu...@li.nux.ro> wrote:

>Guys, I am not a coder to appreciate how sustainable this would be.
>
>Who around here with actual java skills thinks this is achievable in a reasonable way? Cause if it's not we're just wasting time.
>
>Lucian
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
>
>----- Original Message -----
>> From: "Remi Bergsma" <RB...@schubergphilis.com>
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 12 January, 2016 15:36:52
>> Subject: Re: LTS release or not
>
>> Hi,
>> 
>> The method Daan describes can be done from 4.6 and on. It’s about merging a PR
>> with a fix, and forward merging it. Not about actually releasing immediately.
>> 
>> If the bug has always been there, one would merge to 4.6, merge forward to newer
>> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
>> 
>> Regards,
>> Remi
>> 
>> 
>> 
>> On 12/01/16 15:55, "Ron Wheeler" <rw...@artifact-software.com> wrote:
>> 
>>>Depending on how far back the problem originated, this may not be
>>>practical.
>>>The code might have been massaged many times or code may have been
>>>written that depends on the buggy behaviour.
>>>
>>>If the bug "was always there" but no one had figured out the exploit, it
>>>might not be possible to identify any particular commit at all.
>>>
>>>Would your solution trigger a whole bunch of new releases - 4.4.x,
>>>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>>and noted while we wait for enough to accumulate to trigger a new
>>>release? Who would want to work on 4.4.x release?
>>>
>>>The amount of testing required to support all that backporting would
>>>certainly deter people from fixing old bugs!
>>>
>>>No code is bug free so I am not sure how bad it is to say that a bug
>>>will only be fixed in the LTS and current release.
>>>
>>>System administrators can then decide if the bug is worth an update to
>>>the fixed version or should be fixed on the release that they currently
>>>run,  causing a local fork that they will deal with during their next
>>>upgrade cycle.
>>>
>>>
>>>Ron
>>>
>>>
>>>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>>>> commit it was introduced in and thenn be merged forward. It can then be
>>>> merged into any branch that contains the offending commit and there is no
>>>> longer any difference between LTS or anything else. Am I speaking
>>>> Kardeshian? I am really surprised no one in this list sees source code and
>>>> release management this way.
>>>>
>>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>>>>> wrote:
>>>>> There may have to be some rules about patches such as
>>>>> "You may not apply any bug fix to a minor release that will break the
>>>>> upgrade path."
>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>>>> If a user absolutely needs a fix that breaks this, then it is their
>>>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>>>> stable branch.
>>>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>>>> upgraded.
>>>>>
>>>>> Any user that applies the offending patch to 4.6.2 should know that they
>>>>> have created their own misery and will have to work out the upgrade at some
>>>>> point or continue their private fork forever.
>>>>>
>>>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>>>> 4.8.0 and later".
>>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>>>> No piece of software is bug-free so we are really discussing what happens
>>>>> once a bug is found and a fix is available.
>>>>> 4.6.5 will run exactly like it did before the bug was found.
>>>>>
>>>>> Bugs that will cause update issues will trigger a new major release.
>>>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>>>
>>>>>
>>>>> My 2 cents!
>>>>> Ron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>>>
>>>>>> Hi Remi
>>>>>>
>>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>>>
>>>>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>>>>> there yet.
>>>>>>>
>>>>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>>>>> for LTS. This would work right?
>>>>>>
>>>>>> Regards
>>>>>> René
>>>>>>
>>>>>>
>>>>> --
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>>>
>>>>
>>>
>>>
>>>--
>>>Ron Wheeler
>>>President
>>>Artifact Software Inc
>>>email: rwheeler@artifact-software.com
>>>skype: ronaldmwheeler
>>>phone: 866-970-2435, ext 102

Re: LTS release or not

[Nux! <nu...@li.nux.ro>]

Guys, I am not a coder to appreciate how sustainable this would be.

Who around here with actual java skills thinks this is achievable in a reasonable way? Cause if it's not we're just wasting time.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Remi Bergsma" <RB...@schubergphilis.com>
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 12 January, 2016 15:36:52
> Subject: Re: LTS release or not

> Hi,
> 
> The method Daan describes can be done from 4.6 and on. It’s about merging a PR
> with a fix, and forward merging it. Not about actually releasing immediately.
> 
> If the bug has always been there, one would merge to 4.6, merge forward to newer
> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
> 
> Regards,
> Remi
> 
> 
> 
> On 12/01/16 15:55, "Ron Wheeler" <rw...@artifact-software.com> wrote:
> 
>>Depending on how far back the problem originated, this may not be
>>practical.
>>The code might have been massaged many times or code may have been
>>written that depends on the buggy behaviour.
>>
>>If the bug "was always there" but no one had figured out the exploit, it
>>might not be possible to identify any particular commit at all.
>>
>>Would your solution trigger a whole bunch of new releases - 4.4.x,
>>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>and noted while we wait for enough to accumulate to trigger a new
>>release? Who would want to work on 4.4.x release?
>>
>>The amount of testing required to support all that backporting would
>>certainly deter people from fixing old bugs!
>>
>>No code is bug free so I am not sure how bad it is to say that a bug
>>will only be fixed in the LTS and current release.
>>
>>System administrators can then decide if the bug is worth an update to
>>the fixed version or should be fixed on the release that they currently
>>run,  causing a local fork that they will deal with during their next
>>upgrade cycle.
>>
>>
>>Ron
>>
>>
>>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>>> commit it was introduced in and thenn be merged forward. It can then be
>>> merged into any branch that contains the offending commit and there is no
>>> longer any difference between LTS or anything else. Am I speaking
>>> Kardeshian? I am really surprised no one in this list sees source code and
>>> release management this way.
>>>
>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>>>> wrote:
>>>> There may have to be some rules about patches such as
>>>> "You may not apply any bug fix to a minor release that will break the
>>>> upgrade path."
>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>>> If a user absolutely needs a fix that breaks this, then it is their
>>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>>> stable branch.
>>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>>> upgraded.
>>>>
>>>> Any user that applies the offending patch to 4.6.2 should know that they
>>>> have created their own misery and will have to work out the upgrade at some
>>>> point or continue their private fork forever.
>>>>
>>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>>> 4.8.0 and later".
>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>>> No piece of software is bug-free so we are really discussing what happens
>>>> once a bug is found and a fix is available.
>>>> 4.6.5 will run exactly like it did before the bug was found.
>>>>
>>>> Bugs that will cause update issues will trigger a new major release.
>>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>>
>>>>
>>>> My 2 cents!
>>>> Ron
>>>>
>>>>
>>>>
>>>>
>>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>>
>>>>> Hi Remi
>>>>>
>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>>
>>>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>>>> there yet.
>>>>>>
>>>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>>>> for LTS. This would work right?
>>>>>
>>>>> Regards
>>>>> René
>>>>>
>>>>>
>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>
>>
>>
>>--
>>Ron Wheeler
>>President
>>Artifact Software Inc
>>email: rwheeler@artifact-software.com
>>skype: ronaldmwheeler
>>phone: 866-970-2435, ext 102

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

thanks Remi, I think I we agree.

On Mon, Jan 11, 2016 at 4:16 PM, Remi Bergsma <RB...@schubergphilis.com>
wrote:

> Guys,
>
> IMHO we should pick 4.7 instead of 4.6 as it has newer features (like the
> Metrics UI and some more stuff). Apart from that 4.7 has had more bug
> fixes. These could have been merged to 4.6, but we didn’t always do that.
> Let’s make sure we keep doing that for 4.7, also when 4.8 is out. Apart
> from that 4.7.0 == 4.6.2. If one upgrade is easy, it’s 4.6.2 to 4.7.0 so
> let’s not bother. Pick 4.7, it’s better. Trust me.
>
> I also say, should we want to do something LTS-like, we pick a branch, aka
> '4.7’, rather than a specific version like ‘4.7.1’ etc. Don’t see how we
> could LTS a single version.
>
> Maintaining LTS is harder than it seems. For example with upgrading. You
> can only upgrade to versions that are released _after_ the specific LTS
> version. This due to the way upgrades work. If you release 4.7.7 when we’re
> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
> these versions were released. (4.5.3 has been accounted for so that does
> work this time). If you want to keep doing 4.5 releases 18 months from now,
> that’s going to be a real issue. Users probably won’t understand and expect
> it to work. And yes, we will change the upgrading procedures but it’s not
> there yet.
>
> I do understand people want to make 4.5 LTS instead of a more recent
> version. Except for the above, it’s doable. It’s a lot of extra work, but
> if people feel it’s worth it they can of course do it. Rohit for example
> also maintained 4.3 for a long time. Pre-4.6 back porting was the way to
> go, so you can continue to do that. From 4.6, the workflow is based on
> forward-merging, as Daan explained so no cherry-picking there.
>
> Generally speaking, I don’t like it when people have a strong opinion on
> something and they don’t work on it themselves. So, as I probably won’t be
> working on LTS releases, I won’t -1 it for this reason. I'm just trying to
> help understand what it’d be like.
>
> Regards,
> Remi
>
>
>
>
> On 11/01/16 14:47, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>
> >
> >> On Jan 11, 2016, at 2:41 PM, Nux! <nu...@li.nux.ro> wrote:
> >>
> >> Daan,
> >>
> >> Ok, that sounds good, but at this point it's really up to the people
> writing actual code.
> >> Wido has already voted against it and SBP guys don't seem too keen on
> it either.
> >>
> >
> >Exactly, we can say we want an LTS, but then we need a RM.
> >
> >and FWIW, I would think we want to LTS starting with 4.6.2.
> >
> >We need to make sure all upgrade to 4.6.2 work and start there.
> >
> >The reason being that subsequent upgrade and LTS maintenance should be
> much easier as the upstream ( 4.7+) gets the benefit of the new workflow.
> >
> >
> >
> >
> >> --
> >> 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>
> >>> Sent: Monday, 11 January, 2016 13:36:06
> >>> Subject: Re: LTS release or not
> >>
> >>> Any version that is not a year old should be LTS in my view. We must as
> >>> reviewers take care that fixes are merged on the oldest branch first
> and
> >>> then merged forward along the line. To me this was the whole purpose
> of the
> >>> changes we did to our release process. Are we abandonning this now to
> >>> return to fixing on seperate branches and have the same fix in multiple
> >>> commitishes? Excuse my Dutch: That sucks.
> >>>
> >>> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:
> >>>
> >>>> I think LTS is a good idea, but I am afraid we'd be spreading
> ourselves
> >>>> too thin with maintaining that in addition to mainline.
> >>>>
> >>>> The way I see it, one way to have this sorted is by means of
> commercial
> >>>> offerings from companies such as ShapeBlue.
> >>>>
> >>>> What lifetime are we talking rougly for an LTS release? 6 months, 12
> >>>> months?
> >>>>
> >>>> 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>
> >>>>> Sent: Monday, 11 January, 2016 13:19:48
> >>>>> Subject: Re: LTS release or not
> >>>>
> >>>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net>
> wrote:
> >>>>>
> >>>>>>>> * Fix must be important.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Who defines what 'important' is?
> >>>>>>
> >>>>>> "must be important" means we do not backport trivial things like
> typos
> >>>>>> in docs and so forth, only important things. And I would say
> important
> >>>>>> in a common sense. But it doesn't mean that all important fixes
> will be
> >>>>>> backportable, because they may not be necessary "obvious and small".
> >>>>>>
> >>>>>
> >>>>> ​if it is really important it should be fixed on the LTS first and
> then
> >>>>> merged to 'bleeding edge' if still applicable.
> >>>>> ​
> >>>>> ​Limitation of warranty: I really don't like this discussion as it
> >>>> negates
> >>>>> most of the hard weekend work I did over the last half year.​
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Daan
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >
>



-- 
Daan

Re: LTS release or not

[Remi Bergsma <RB...@schubergphilis.com>]

Hi René,

Yes, except there’s nothing in CloudStack that can handle such a version and I’m unsure if the extra dot works. If you call it 4.5.2-1 it works. You could only give the package a new version and then re-release 4.5.2. Although that probably is not compatible with the Apache release process as we release source on a given git hash. We’d then vote on the same version multiple times.

Technically it works, I deployed 4.7.1-SNAPSHOT several times.

Regards,
Remi




On 11/01/16 16:23, "Rene Moser" <ma...@renemoser.net> wrote:

>Hi Remi
>
>On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>> Maintaining LTS is harder than it seems. For example with upgrading. You can only upgrade to versions that are released _after_ the specific LTS version. This due to the way upgrades work. If you release 4.7.7 when we’re on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4 cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when these versions were released. (4.5.3 has been accounted for so that does work this time). If you want to keep doing 4.5 releases 18 months from now, that’s going to be a real issue. Users probably won’t understand and expect it to work. And yes, we will change the upgrading procedures but it’s not there yet.
>
>Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>for LTS. This would work right?
>
>Regards
>René

Re: LTS release or not

[Remi Bergsma <RB...@schubergphilis.com>]

Hi,

The method Daan describes can be done from 4.6 and on. It’s about merging a PR with a fix, and forward merging it. Not about actually releasing immediately. 

If the bug has always been there, one would merge to 4.6, merge forward to newer releases (and finally master) and then back port (aka cherry-pick) to 4.5.

Regards,
Remi



On 12/01/16 15:55, "Ron Wheeler" <rw...@artifact-software.com> wrote:

>Depending on how far back the problem originated, this may not be 
>practical.
>The code might have been massaged many times or code may have been 
>written that depends on the buggy behaviour.
>
>If the bug "was always there" but no one had figured out the exploit, it 
>might not be possible to identify any particular commit at all.
>
>Would your solution trigger a whole bunch of new releases - 4.4.x, 
>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch 
>and noted while we wait for enough to accumulate to trigger a new 
>release? Who would want to work on 4.4.x release?
>
>The amount of testing required to support all that backporting would 
>certainly deter people from fixing old bugs!
>
>No code is bug free so I am not sure how bad it is to say that a bug 
>will only be fixed in the LTS and current release.
>
>System administrators can then decide if the bug is worth an update to 
>the fixed version or should be fixed on the release that they currently 
>run,  causing a local fork that they will deal with during their next 
>upgrade cycle.
>
>
>Ron
>
>
>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>> commit it was introduced in and thenn be merged forward. It can then be
>> merged into any branch that contains the offending commit and there is no
>> longer any difference between LTS or anything else. Am I speaking
>> Kardeshian? I am really surprised no one in this list sees source code and
>> release management this way.
>>
>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>>> wrote:
>>> There may have to be some rules about patches such as
>>> "You may not apply any bug fix to a minor release that will break the
>>> upgrade path."
>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>> If a user absolutely needs a fix that breaks this, then it is their
>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>> stable branch.
>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>> upgraded.
>>>
>>> Any user that applies the offending patch to 4.6.2 should know that they
>>> have created their own misery and will have to work out the upgrade at some
>>> point or continue their private fork forever.
>>>
>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>> 4.8.0 and later".
>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>> No piece of software is bug-free so we are really discussing what happens
>>> once a bug is found and a fix is available.
>>> 4.6.5 will run exactly like it did before the bug was found.
>>>
>>> Bugs that will cause update issues will trigger a new major release.
>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>
>>>
>>> My 2 cents!
>>> Ron
>>>
>>>
>>>
>>>
>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>
>>>> Hi Remi
>>>>
>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>
>>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>>> there yet.
>>>>>
>>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>>> for LTS. This would work right?
>>>>
>>>> Regards
>>>> René
>>>>
>>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>
>
>
>-- 
>Ron Wheeler
>President
>Artifact Software Inc
>email: rwheeler@artifact-software.com
>skype: ronaldmwheeler
>phone: 866-970-2435, ext 102
>

Re: LTS release or not

[Ron Wheeler <rw...@artifact-software.com>]

Depending on how far back the problem originated, this may not be 
practical.
The code might have been massaged many times or code may have been 
written that depends on the buggy behaviour.

If the bug "was always there" but no one had figured out the exploit, it 
might not be possible to identify any particular commit at all.

Would your solution trigger a whole bunch of new releases - 4.4.x, 
4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch 
and noted while we wait for enough to accumulate to trigger a new 
release? Who would want to work on 4.4.x release?

The amount of testing required to support all that backporting would 
certainly deter people from fixing old bugs!

No code is bug free so I am not sure how bad it is to say that a bug 
will only be fixed in the LTS and current release.

System administrators can then decide if the bug is worth an update to 
the fixed version or should be fixed on the release that they currently 
run,  causing a local fork that they will deal with during their next 
upgrade cycle.


Ron


On 12/01/2016 2:18 AM, Daan Hoogland wrote:
> ok, one last €0,01: any bug should be fixed not on the branch but on the
> commit it was introduced in and thenn be merged forward. It can then be
> merged into any branch that contains the offending commit and there is no
> longer any difference between LTS or anything else. Am I speaking
> Kardeshian? I am really surprised no one in this list sees source code and
> release management this way.
>
> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
>> wrote:
>> There may have to be some rules about patches such as
>> "You may not apply any bug fix to a minor release that will break the
>> upgrade path."
>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>> If a user absolutely needs a fix that breaks this, then it is their
>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>> stable branch.
>> At some point no one will be happy with the latest 4.6.x and everyone will
>> upgraded.
>>
>> Any user that applies the offending patch to 4.6.2 should know that they
>> have created their own misery and will have to work out the upgrade at some
>> point or continue their private fork forever.
>>
>> There is nothing wrong to saying that "Bug xx is only fixed in version
>> 4.8.0 and later".
>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>> No piece of software is bug-free so we are really discussing what happens
>> once a bug is found and a fix is available.
>> 4.6.5 will run exactly like it did before the bug was found.
>>
>> Bugs that will cause update issues will trigger a new major release.
>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>
>>
>> My 2 cents!
>> Ron
>>
>>
>>
>>
>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>
>>> Hi Remi
>>>
>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>
>>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>>> can only upgrade to versions that are released _after_ the specific LTS
>>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>>> these versions were released. (4.5.3 has been accounted for so that does
>>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>>> that’s going to be a real issue. Users probably won’t understand and expect
>>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>>> there yet.
>>>>
>>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>>> for LTS. This would work right?
>>>
>>> Regards
>>> René
>>>
>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

ok, one last €0,01: any bug should be fixed not on the branch but on the
commit it was introduced in and thenn be merged forward. It can then be
merged into any branch that contains the offending commit and there is no
longer any difference between LTS or anything else. Am I speaking
Kardeshian? I am really surprised no one in this list sees source code and
release management this way.

On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> There may have to be some rules about patches such as
> "You may not apply any bug fix to a minor release that will break the
> upgrade path."
> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
> If a user absolutely needs a fix that breaks this, then it is their
> problem to upgrade to 4.7.x rather than building a long-term problem into a
> stable branch.
> At some point no one will be happy with the latest 4.6.x and everyone will
> upgraded.
>
> Any user that applies the offending patch to 4.6.2 should know that they
> have created their own misery and will have to work out the upgrade at some
> point or continue their private fork forever.
>
> There is nothing wrong to saying that "Bug xx is only fixed in version
> 4.8.0 and later".
> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
> No piece of software is bug-free so we are really discussing what happens
> once a bug is found and a fix is available.
> 4.6.5 will run exactly like it did before the bug was found.
>
> Bugs that will cause update issues will trigger a new major release.
> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
> cause a 4.8.0 to come into existence with an upgrade path that goes from
> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>
>
> My 2 cents!
> Ron
>
>
>
>
> On 11/01/2016 10:23 AM, Rene Moser wrote:
>
>> Hi Remi
>>
>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>
>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>> can only upgrade to versions that are released _after_ the specific LTS
>>> version. This due to the way upgrades work. If you release 4.7.7 when we’re
>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>>> these versions were released. (4.5.3 has been accounted for so that does
>>> work this time). If you want to keep doing 4.5 releases 18 months from now,
>>> that’s going to be a real issue. Users probably won’t understand and expect
>>> it to work. And yes, we will change the upgrading procedures but it’s not
>>> there yet.
>>>
>> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
>> for LTS. This would work right?
>>
>> Regards
>> René
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


-- 
Daan

Re: LTS release or not

[Ron Wheeler <rw...@artifact-software.com>]

There may have to be some rules about patches such as
"You may not apply any bug fix to a minor release that will break the 
upgrade path."
So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
If a user absolutely needs a fix that breaks this, then it is their 
problem to upgrade to 4.7.x rather than building a long-term problem 
into a stable branch.
At some point no one will be happy with the latest 4.6.x and everyone 
will upgraded.

Any user that applies the offending patch to 4.6.2 should know that they 
have created their own misery and will have to work out the upgrade at 
some point or continue their private fork forever.

There is nothing wrong to saying that "Bug xx is only fixed in version 
4.8.0 and later".
Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
No piece of software is bug-free so we are really discussing what 
happens once a bug is found and a fix is available.
4.6.5 will run exactly like it did before the bug was found.

Bugs that will cause update issues will trigger a new major release.
If the current supported releases are 4.6.2 and 4.7.1 then the bug will 
cause a 4.8.0 to come into existence with an upgrade path that goes from 
4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0


My 2 cents!
Ron



On 11/01/2016 10:23 AM, Rene Moser wrote:
> Hi Remi
>
> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>> Maintaining LTS is harder than it seems. For example with upgrading. You can only upgrade to versions that are released _after_ the specific LTS version. This due to the way upgrades work. If you release 4.7.7 when we’re on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4 cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when these versions were released. (4.5.3 has been accounted for so that does work this time). If you want to keep doing 4.5 releases 18 months from now, that’s going to be a real issue. Users probably won’t understand and expect it to work. And yes, we will change the upgrading procedures but it’s not there yet.
> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
> for LTS. This would work right?
>
> Regards
> René
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

Hi Remi

On 01/11/2016 04:16 PM, Remi Bergsma wrote:
> Maintaining LTS is harder than it seems. For example with upgrading. You can only upgrade to versions that are released _after_ the specific LTS version. This due to the way upgrades work. If you release 4.7.7 when we’re on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4 cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when these versions were released. (4.5.3 has been accounted for so that does work this time). If you want to keep doing 4.5 releases 18 months from now, that’s going to be a real issue. Users probably won’t understand and expect it to work. And yes, we will change the upgrading procedures but it’s not there yet.

Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
for LTS. This would work right?

Regards
René

Re: LTS release or not

[Remi Bergsma <RB...@schubergphilis.com>]

Guys,

IMHO we should pick 4.7 instead of 4.6 as it has newer features (like the Metrics UI and some more stuff). Apart from that 4.7 has had more bug fixes. These could have been merged to 4.6, but we didn’t always do that. Let’s make sure we keep doing that for 4.7, also when 4.8 is out. Apart from that 4.7.0 == 4.6.2. If one upgrade is easy, it’s 4.6.2 to 4.7.0 so let’s not bother. Pick 4.7, it’s better. Trust me.

I also say, should we want to do something LTS-like, we pick a branch, aka '4.7’, rather than a specific version like ‘4.7.1’ etc. Don’t see how we could LTS a single version.

Maintaining LTS is harder than it seems. For example with upgrading. You can only upgrade to versions that are released _after_ the specific LTS version. This due to the way upgrades work. If you release 4.7.7 when we’re on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4 cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when these versions were released. (4.5.3 has been accounted for so that does work this time). If you want to keep doing 4.5 releases 18 months from now, that’s going to be a real issue. Users probably won’t understand and expect it to work. And yes, we will change the upgrading procedures but it’s not there yet.

I do understand people want to make 4.5 LTS instead of a more recent version. Except for the above, it’s doable. It’s a lot of extra work, but if people feel it’s worth it they can of course do it. Rohit for example also maintained 4.3 for a long time. Pre-4.6 back porting was the way to go, so you can continue to do that. From 4.6, the workflow is based on forward-merging, as Daan explained so no cherry-picking there.

Generally speaking, I don’t like it when people have a strong opinion on something and they don’t work on it themselves. So, as I probably won’t be working on LTS releases, I won’t -1 it for this reason. I'm just trying to help understand what it’d be like.

Regards,
Remi




On 11/01/16 14:47, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>
>> On Jan 11, 2016, at 2:41 PM, Nux! <nu...@li.nux.ro> wrote:
>> 
>> Daan,
>> 
>> Ok, that sounds good, but at this point it's really up to the people writing actual code.
>> Wido has already voted against it and SBP guys don't seem too keen on it either.
>> 
>
>Exactly, we can say we want an LTS, but then we need a RM.
>
>and FWIW, I would think we want to LTS starting with 4.6.2.
>
>We need to make sure all upgrade to 4.6.2 work and start there.
>
>The reason being that subsequent upgrade and LTS maintenance should be much easier as the upstream ( 4.7+) gets the benefit of the new workflow.
>
>
>
>
>> --
>> 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>
>>> Sent: Monday, 11 January, 2016 13:36:06
>>> Subject: Re: LTS release or not
>> 
>>> Any version that is not a year old should be LTS in my view. We must as
>>> reviewers take care that fixes are merged on the oldest branch first and
>>> then merged forward along the line. To me this was the whole purpose of the
>>> changes we did to our release process. Are we abandonning this now to
>>> return to fixing on seperate branches and have the same fix in multiple
>>> commitishes? Excuse my Dutch: That sucks.
>>> 
>>> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:
>>> 
>>>> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
>>>> too thin with maintaining that in addition to mainline.
>>>> 
>>>> The way I see it, one way to have this sorted is by means of commercial
>>>> offerings from companies such as ShapeBlue.
>>>> 
>>>> What lifetime are we talking rougly for an LTS release? 6 months, 12
>>>> months?
>>>> 
>>>> 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>
>>>>> Sent: Monday, 11 January, 2016 13:19:48
>>>>> Subject: Re: LTS release or not
>>>> 
>>>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:
>>>>> 
>>>>>>>> * Fix must be important.
>>>>>>>> 
>>>>>>> 
>>>>>>> Who defines what 'important' is?
>>>>>> 
>>>>>> "must be important" means we do not backport trivial things like typos
>>>>>> in docs and so forth, only important things. And I would say important
>>>>>> in a common sense. But it doesn't mean that all important fixes will be
>>>>>> backportable, because they may not be necessary "obvious and small".
>>>>>> 
>>>>> 
>>>>> ​if it is really important it should be fixed on the LTS first and then
>>>>> merged to 'bleeding edge' if still applicable.
>>>>> ​
>>>>> ​Limitation of warranty: I really don't like this discussion as it
>>>> negates
>>>>> most of the hard weekend work I did over the last half year.​
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Daan
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Daan
>

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

My point is that no backporting should have to take place. Wido and SBP
should be convinced of the improved way of working and we shouldn't try to
patch a less ideal way of working into something acceptable if we already
have a good thing. I will start -1 any patch to 4.8 that could also go
against 4.7. I have not with 4.6 yet and that was a mistake. We are
reversing the improvements of our release process.

On Mon, Jan 11, 2016 at 2:47 PM, Sebastien Goasguen <ru...@gmail.com>
wrote:

>
> > On Jan 11, 2016, at 2:41 PM, Nux! <nu...@li.nux.ro> wrote:
> >
> > Daan,
> >
> > Ok, that sounds good, but at this point it's really up to the people
> writing actual code.
> > Wido has already voted against it and SBP guys don't seem too keen on it
> either.
> >
>
> Exactly, we can say we want an LTS, but then we need a RM.
>
> and FWIW, I would think we want to LTS starting with 4.6.2.
>
> We need to make sure all upgrade to 4.6.2 work and start there.
>
> The reason being that subsequent upgrade and LTS maintenance should be
> much easier as the upstream ( 4.7+) gets the benefit of the new workflow.
>
>
>
>
> > --
> > 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>
> >> Sent: Monday, 11 January, 2016 13:36:06
> >> Subject: Re: LTS release or not
> >
> >> Any version that is not a year old should be LTS in my view. We must as
> >> reviewers take care that fixes are merged on the oldest branch first and
> >> then merged forward along the line. To me this was the whole purpose of
> the
> >> changes we did to our release process. Are we abandonning this now to
> >> return to fixing on seperate branches and have the same fix in multiple
> >> commitishes? Excuse my Dutch: That sucks.
> >>
> >> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:
> >>
> >>> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
> >>> too thin with maintaining that in addition to mainline.
> >>>
> >>> The way I see it, one way to have this sorted is by means of commercial
> >>> offerings from companies such as ShapeBlue.
> >>>
> >>> What lifetime are we talking rougly for an LTS release? 6 months, 12
> >>> months?
> >>>
> >>> 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>
> >>>> Sent: Monday, 11 January, 2016 13:19:48
> >>>> Subject: Re: LTS release or not
> >>>
> >>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net>
> wrote:
> >>>>
> >>>>>>> * Fix must be important.
> >>>>>>>
> >>>>>>
> >>>>>> Who defines what 'important' is?
> >>>>>
> >>>>> "must be important" means we do not backport trivial things like
> typos
> >>>>> in docs and so forth, only important things. And I would say
> important
> >>>>> in a common sense. But it doesn't mean that all important fixes will
> be
> >>>>> backportable, because they may not be necessary "obvious and small".
> >>>>>
> >>>>
> >>>> ​if it is really important it should be fixed on the LTS first and
> then
> >>>> merged to 'bleeding edge' if still applicable.
> >>>> ​
> >>>> ​Limitation of warranty: I really don't like this discussion as it
> >>> negates
> >>>> most of the hard weekend work I did over the last half year.​
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Daan
> >>>
> >>
> >>
> >>
> >> --
> >> Daan
>
>


-- 
Daan

Re: LTS release or not

[Sebastien Goasguen <ru...@gmail.com>]

> On Jan 11, 2016, at 2:41 PM, Nux! <nu...@li.nux.ro> wrote:
> 
> Daan,
> 
> Ok, that sounds good, but at this point it's really up to the people writing actual code.
> Wido has already voted against it and SBP guys don't seem too keen on it either.
> 

Exactly, we can say we want an LTS, but then we need a RM.

and FWIW, I would think we want to LTS starting with 4.6.2.

We need to make sure all upgrade to 4.6.2 work and start there.

The reason being that subsequent upgrade and LTS maintenance should be much easier as the upstream ( 4.7+) gets the benefit of the new workflow.




> --
> 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>
>> Sent: Monday, 11 January, 2016 13:36:06
>> Subject: Re: LTS release or not
> 
>> Any version that is not a year old should be LTS in my view. We must as
>> reviewers take care that fixes are merged on the oldest branch first and
>> then merged forward along the line. To me this was the whole purpose of the
>> changes we did to our release process. Are we abandonning this now to
>> return to fixing on seperate branches and have the same fix in multiple
>> commitishes? Excuse my Dutch: That sucks.
>> 
>> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:
>> 
>>> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
>>> too thin with maintaining that in addition to mainline.
>>> 
>>> The way I see it, one way to have this sorted is by means of commercial
>>> offerings from companies such as ShapeBlue.
>>> 
>>> What lifetime are we talking rougly for an LTS release? 6 months, 12
>>> months?
>>> 
>>> 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>
>>>> Sent: Monday, 11 January, 2016 13:19:48
>>>> Subject: Re: LTS release or not
>>> 
>>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:
>>>> 
>>>>>>> * Fix must be important.
>>>>>>> 
>>>>>> 
>>>>>> Who defines what 'important' is?
>>>>> 
>>>>> "must be important" means we do not backport trivial things like typos
>>>>> in docs and so forth, only important things. And I would say important
>>>>> in a common sense. But it doesn't mean that all important fixes will be
>>>>> backportable, because they may not be necessary "obvious and small".
>>>>> 
>>>> 
>>>> ​if it is really important it should be fixed on the LTS first and then
>>>> merged to 'bleeding edge' if still applicable.
>>>> ​
>>>> ​Limitation of warranty: I really don't like this discussion as it
>>> negates
>>>> most of the hard weekend work I did over the last half year.​
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Daan
>>> 
>> 
>> 
>> 
>> --
>> Daan

Re: LTS release or not

[Nux! <nu...@li.nux.ro>]

Daan,

Ok, that sounds good, but at this point it's really up to the people writing actual code.
Wido has already voted against it and SBP guys don't seem too keen on it either.

--
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>
> Sent: Monday, 11 January, 2016 13:36:06
> Subject: Re: LTS release or not

> Any version that is not a year old should be LTS in my view. We must as
> reviewers take care that fixes are merged on the oldest branch first and
> then merged forward along the line. To me this was the whole purpose of the
> changes we did to our release process. Are we abandonning this now to
> return to fixing on seperate branches and have the same fix in multiple
> commitishes? Excuse my Dutch: That sucks.
> 
> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:
> 
>> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
>> too thin with maintaining that in addition to mainline.
>>
>> The way I see it, one way to have this sorted is by means of commercial
>> offerings from companies such as ShapeBlue.
>>
>> What lifetime are we talking rougly for an LTS release? 6 months, 12
>> months?
>>
>> 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>
>> > Sent: Monday, 11 January, 2016 13:19:48
>> > Subject: Re: LTS release or not
>>
>> > On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:
>> >
>> >> >> * Fix must be important.
>> >> >>
>> >> >
>> >> > Who defines what 'important' is?
>> >>
>> >> "must be important" means we do not backport trivial things like typos
>> >> in docs and so forth, only important things. And I would say important
>> >> in a common sense. But it doesn't mean that all important fixes will be
>> >> backportable, because they may not be necessary "obvious and small".
>> >>
>> >
>> > ​if it is really important it should be fixed on the LTS first and then
>> > merged to 'bleeding edge' if still applicable.
>> > ​
>> > ​Limitation of warranty: I really don't like this discussion as it
>> negates
>> > most of the hard weekend work I did over the last half year.​
>> >
>> >
>> >
>> > --
>> > Daan
>>
> 
> 
> 
> --
> Daan

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

Any version that is not a year old should be LTS in my view. We must as
reviewers take care that fixes are merged on the oldest branch first and
then merged forward along the line. To me this was the whole purpose of the
changes we did to our release process. Are we abandonning this now to
return to fixing on seperate branches and have the same fix in multiple
commitishes? Excuse my Dutch: That sucks.

On Mon, Jan 11, 2016 at 2:28 PM, Nux! <nu...@li.nux.ro> wrote:

> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
> too thin with maintaining that in addition to mainline.
>
> The way I see it, one way to have this sorted is by means of commercial
> offerings from companies such as ShapeBlue.
>
> What lifetime are we talking rougly for an LTS release? 6 months, 12
> months?
>
> 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>
> > Sent: Monday, 11 January, 2016 13:19:48
> > Subject: Re: LTS release or not
>
> > On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:
> >
> >> >> * Fix must be important.
> >> >>
> >> >
> >> > Who defines what 'important' is?
> >>
> >> "must be important" means we do not backport trivial things like typos
> >> in docs and so forth, only important things. And I would say important
> >> in a common sense. But it doesn't mean that all important fixes will be
> >> backportable, because they may not be necessary "obvious and small".
> >>
> >
> > ​if it is really important it should be fixed on the LTS first and then
> > merged to 'bleeding edge' if still applicable.
> > ​
> > ​Limitation of warranty: I really don't like this discussion as it
> negates
> > most of the hard weekend work I did over the last half year.​
> >
> >
> >
> > --
> > Daan
>



-- 
Daan

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

On 01/11/2016 02:28 PM, Nux! wrote:

> What lifetime are we talking rougly for an LTS release? 6 months, 12 months?

I thought about 18 months. After 12 months we define a new LTS.

So users have a 6 months time frame to switch from LTS to LTS.

Re: LTS release or not

[Nux! <nu...@li.nux.ro>]

I think LTS is a good idea, but I am afraid we'd be spreading ourselves too thin with maintaining that in addition to mainline.

The way I see it, one way to have this sorted is by means of commercial offerings from companies such as ShapeBlue.

What lifetime are we talking rougly for an LTS release? 6 months, 12 months?

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>
> Sent: Monday, 11 January, 2016 13:19:48
> Subject: Re: LTS release or not

> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:
> 
>> >> * Fix must be important.
>> >>
>> >
>> > Who defines what 'important' is?
>>
>> "must be important" means we do not backport trivial things like typos
>> in docs and so forth, only important things. And I would say important
>> in a common sense. But it doesn't mean that all important fixes will be
>> backportable, because they may not be necessary "obvious and small".
>>
> 
> ​if it is really important it should be fixed on the LTS first and then
> merged to 'bleeding edge' if still applicable.
> ​
> ​Limitation of warranty: I really don't like this discussion as it negates
> most of the hard weekend work I did over the last half year.​
> 
> 
> 
> --
> Daan

Re: LTS release or not

[Daan Hoogland <da...@gmail.com>]

On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <ma...@renemoser.net> wrote:

> >> * Fix must be important.
> >>
> >
> > Who defines what 'important' is?
>
> "must be important" means we do not backport trivial things like typos
> in docs and so forth, only important things. And I would say important
> in a common sense. But it doesn't mean that all important fixes will be
> backportable, because they may not be necessary "obvious and small".
>

​if it is really important it should be fixed on the LTS first and then
merged to 'bleeding edge' if still applicable.
​
​Limitation of warranty: I really don't like this discussion as it negates
most of the hard weekend work I did over the last half year.​



-- 
Daan

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

On 01/10/2016 11:46 PM, Erik Weber wrote:

> What if the fix is part of a refactorization or a new feature?
> Providing a LTS is not 'easy as pie' with a product like CloudStack where a
> lot of code changes over time.

Didn't say it's easy :)

Yes re-factorization is one of the unsolved "problems". That is why I
wrote, squashing is evil for fixing bugs.

It is important that devs fix the bug first, commit and then do the
refactor commits

If the devs fixed it by "mistake" somehow in the refactor in the past,
then we can decide if we can re-implement the fix without refactor (aka
it would be "obvious and small"). LTS would not mean we fix all the bugs.

> For instance, /if/ the strongswan feature is merged to 4.8, how to you
> handle /ANY/ VPN fixes in 4.5 since they don't even use the same software?
> And the whole VR process was refactored in 4.6 -- meaning you won't be
> using the same scripts, or even the same language.

Yes, we must dedicated from fix to fix. How and if.

> Even if a bugfix is included in master and tested, it is impossible to say
> how it will react with an older/different solution.

It depends, for sure testing must also be done.

> The same can be said for library updates etc.
> 
> Don't get me wrong, I'm not opposing a LTS version -- actually I would
> rather like to have one. I just want to be clear about the fact that it
> won't be always be easy, and not all fixes might be possible to backport --
> depending on how strict you'll be with 3rd party stuff.

That is fine, I am aware of that.

>> * Fix must be important.
>>
> 
> Who defines what 'important' is?

"must be important" means we do not backport trivial things like typos
in docs and so forth, only important things. And I would say important
in a common sense. But it doesn't mean that all important fixes will be
backportable, because they may not be necessary "obvious and small".


> On a last note, doing LTS -- atleast in my opinion -- requires commitment.
> Anything called LTS is usually getting a lot of user focus/traction and
> have to be rock solid and maintained.

That is why I started this thread, I would see a commitment, that _we_
as community provide a LTS for those who need it.

Re: LTS release or not

[Erik Weber <te...@gmail.com>]

On Sun, Jan 10, 2016 at 10:27 PM, Rene Moser <ma...@renemoser.net> wrote:

>
> On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> > Ok, understood. However, it will be up to users on their own to pick
> > this LTS maintainment up.
>
> It would be up to the devs making fixes small (so no squashing for
> fixes) and notify the one maintaining the LTS version if they feel the
> fix is that important to be in LTS. Wouldn't be that hard work.
>
>
What if the fix is part of a refactorization or a new feature?
Providing a LTS is not 'easy as pie' with a product like CloudStack where a
lot of code changes over time.

For instance, /if/ the strongswan feature is merged to 4.8, how to you
handle /ANY/ VPN fixes in 4.5 since they don't even use the same software?
And the whole VR process was refactored in 4.6 -- meaning you won't be
using the same scripts, or even the same language.

Even if a bugfix is included in master and tested, it is impossible to say
how it will react with an older/different solution.

The same can be said for library updates etc.

Don't get me wrong, I'm not opposing a LTS version -- actually I would
rather like to have one. I just want to be clear about the fact that it
won't be always be easy, and not all fixes might be possible to backport --
depending on how strict you'll be with 3rd party stuff.



> > That means testing, releasing, testing, backporting, testing, releasing.
> >
> > Certain users will focus on getting new releases out and others on doing
> > LTS work.
>
> The process of backporting is not defined yet, but I would like to adopt
> the Linux kernel long term policy:
>
> * Fix must be already in mainline
>

See above, the fix might not be necessary in master/mainline.


> * Fix must be important.
>

Who defines what 'important' is?


> * Fix must be obvious and small.
>
> Which means, we only fix stuff in LTS which is already fixed in
> mainline. Important stuff only.
>
> We can even define, the mainline version must be released with the fix,
> before getting into LTS. So even the LTS releases would be behind the
> mainline releases and the fix has been tested in mainline.
>

On a last note, doing LTS -- atleast in my opinion -- requires commitment.
Anything called LTS is usually getting a lot of user focus/traction and
have to be rock solid and maintained.

-- 
Erik

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> Ok, understood. However, it will be up to users on their own to pick
> this LTS maintainment up.

It would be up to the devs making fixes small (so no squashing for
fixes) and notify the one maintaining the LTS version if they feel the
fix is that important to be in LTS. Wouldn't be that hard work.

> That means testing, releasing, testing, backporting, testing, releasing.
> 
> Certain users will focus on getting new releases out and others on doing
> LTS work.

The process of backporting is not defined yet, but I would like to adopt
the Linux kernel long term policy:

* Fix must be already in mainline
* Fix must be important.
* Fix must be obvious and small.

Which means, we only fix stuff in LTS which is already fixed in
mainline. Important stuff only.

We can even define, the mainline version must be released with the fix,
before getting into LTS. So even the LTS releases would be behind the
mainline releases and the fix has been tested in mainline.

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> Ok, understood. However, it will be up to users on their own to pick
> this LTS maintainment up.

It would be up to the devs making fixes small (so no squashing for
fixes) and notify the one maintaining the LTS version if they feel the
fix is that important to be in LTS. Wouldn't be that hard work.

> That means testing, releasing, testing, backporting, testing, releasing.
> 
> Certain users will focus on getting new releases out and others on doing
> LTS work.

The process of backporting is not defined yet, but I would like to adopt
the Linux kernel long term policy:

* Fix must be already in mainline
* Fix must be important.
* Fix must be obvious and small.

Which means, we only fix stuff in LTS which is already fixed in
mainline. Important stuff only.

We can even define, the mainline version must be released with the fix,
before getting into LTS. So even the LTS releases would be behind the
mainline releases and the fix has been tested in mainline.

Re: LTS release or not

[Wido den Hollander <wi...@widodh.nl>]

On 01/10/2016 09:58 PM, Rene Moser wrote:
> Hi Wido
> 
> On 01/10/2016 08:23 PM, Wido den Hollander wrote:
>> I personally am against LTS versions. If we keep the release cycle short
>> enough each .1 increment in version will only include a very small set
>> of features and bug fixes.
>>
>> In the old days it took months for a release, if we bring that back to
>> weeks the amount of changes are minimal.
> 
> The current release process is fine! We don't want to change that! No way!
> 
> It fits the needs of those CloudStack users who want features fast and a
> minimal of risk.
> 
>> You can then decide to always stay behind 3 months on the releases or
>> suddenly make a jump if you want to.
> 
> No, unfortunately some of the users can not do that (yet). Staying 3
> months behind fixes (security?) is not an option. In my case it would be
> even longer 6-12 months. For those, an _additinoal_ LTS version would be
> the way to go.
> 
>> In my perspective clouds are agile and they should be developed that way.
> 
> I fully agree with development, development could go even more agile,
> releases can be agile as well, the problems come when the applications
> go into operation.
> 
> If the operation is not ready for deploying agile, those users will left
> behind.
> 
> The only thing we need to do is backport fixes to a separate LTS branch.
> That's it.
> 
> Only fixes, obvious fixes.
> 
>> We should however simplify the upgrade even more:
>> - Separate database changes from code changes (proposed already)
>> - Put the VR in a separate project
> 
> Yes, all fine with that.
> 
> Again. I do not want to slow down development and releases.
> 
> An additional LTS version could even help agile development because you
> can always rely on the argument:
> 
> If you want most annoying stable cloudstack, use LTS. If you want to get
> features fast, use mainline. This is the trade off.
> 

Ok, understood. However, it will be up to users on their own to pick
this LTS maintainment up.

That means testing, releasing, testing, backporting, testing, releasing.

Certain users will focus on getting new releases out and others on doing
LTS work.

Wido

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

Hi Wido

On 01/10/2016 08:23 PM, Wido den Hollander wrote:
> I personally am against LTS versions. If we keep the release cycle short
> enough each .1 increment in version will only include a very small set
> of features and bug fixes.
> 
> In the old days it took months for a release, if we bring that back to
> weeks the amount of changes are minimal.

The current release process is fine! We don't want to change that! No way!

It fits the needs of those CloudStack users who want features fast and a
minimal of risk.

> You can then decide to always stay behind 3 months on the releases or
> suddenly make a jump if you want to.

No, unfortunately some of the users can not do that (yet). Staying 3
months behind fixes (security?) is not an option. In my case it would be
even longer 6-12 months. For those, an _additinoal_ LTS version would be
the way to go.

> In my perspective clouds are agile and they should be developed that way.

I fully agree with development, development could go even more agile,
releases can be agile as well, the problems come when the applications
go into operation.

If the operation is not ready for deploying agile, those users will left
behind.

The only thing we need to do is backport fixes to a separate LTS branch.
That's it.

Only fixes, obvious fixes.

> We should however simplify the upgrade even more:
> - Separate database changes from code changes (proposed already)
> - Put the VR in a separate project

Yes, all fine with that.

Again. I do not want to slow down development and releases.

An additional LTS version could even help agile development because you
can always rely on the argument:

If you want most annoying stable cloudstack, use LTS. If you want to get
features fast, use mainline. This is the trade off.

Re: LTS release or not

[Rene Moser <ma...@renemoser.net>]

Hi Wido

On 01/10/2016 08:23 PM, Wido den Hollander wrote:
> I personally am against LTS versions. If we keep the release cycle short
> enough each .1 increment in version will only include a very small set
> of features and bug fixes.
> 
> In the old days it took months for a release, if we bring that back to
> weeks the amount of changes are minimal.

The current release process is fine! We don't want to change that! No way!

It fits the needs of those CloudStack users who want features fast and a
minimal of risk.

> You can then decide to always stay behind 3 months on the releases or
> suddenly make a jump if you want to.

No, unfortunately some of the users can not do that (yet). Staying 3
months behind fixes (security?) is not an option. In my case it would be
even longer 6-12 months. For those, an _additinoal_ LTS version would be
the way to go.

> In my perspective clouds are agile and they should be developed that way.

I fully agree with development, development could go even more agile,
releases can be agile as well, the problems come when the applications
go into operation.

If the operation is not ready for deploying agile, those users will left
behind.

The only thing we need to do is backport fixes to a separate LTS branch.
That's it.

Only fixes, obvious fixes.

> We should however simplify the upgrade even more:
> - Separate database changes from code changes (proposed already)
> - Put the VR in a separate project

Yes, all fine with that.

Again. I do not want to slow down development and releases.

An additional LTS version could even help agile development because you
can always rely on the argument:

If you want most annoying stable cloudstack, use LTS. If you want to get
features fast, use mainline. This is the trade off.

Re: LTS release or not

[Wido den Hollander <wi...@widodh.nl>]

On 01/09/2016 11:51 PM, Rene Moser wrote:
> Hi
> 
> I recently started a discussion about the current release process. You
> may have noticed that CloudStack had a few releases in the last 2 months.
> 
> My concerns were that many CloudStack users will be confused about these
> many releases (which one to take? Are fixes backported? How long will it
> receive fixes? Do I have to upgrade?).
> 
> We leads me to the question: Does CloudStack need an LTS version? To me
> it would make sense in many ways:
> 
> * Users in restrictive cloud environments can choose LTS for getting
> backwards compatible bug fixes only.
> 
> * Users in agile cloud environments can choose latest stable and getting
> new features fast.
> 
> * CloudStack developers must only maintain the latest stable (mainline)
> and the LTS version.
> 
> * CloudStack developers and mainline users can accept, that mainline may
> break environments but will receive fast forward fixes.
> 
> To me this would make a lot of sense. I am actually thinking about
> maintaining 4.5 as a LTS by myself.
> 
> Any thoughts? +1/-1?
> 

I personally am against LTS versions. If we keep the release cycle short
enough each .1 increment in version will only include a very small set
of features and bug fixes.

In the old days it took months for a release, if we bring that back to
weeks the amount of changes are minimal.

You can then decide to always stay behind 3 months on the releases or
suddenly make a jump if you want to.

In my perspective clouds are agile and they should be developed that way.

We should however simplify the upgrade even more:
- Separate database changes from code changes (proposed already)
- Put the VR in a separate project

> Regards
> René
> 

Summary: -1 LTS

[Rene Moser <ma...@renemoser.net>]

LTS by the community is not an option for now:

Most of the threads/users/devs had concerns or are skeptical how it can
be done in practice.

As we recently changed the release process, it seems to "early" to
change it again or add new processes to it.

I still think CloudStack need some kind of LTS to serve business needs
but unsure if _we_ as community should do it.

Thanks for participating.

Regards
René