Re: LTS release or not
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.burw...@shapeblue.com | t: <mailto:john.burw...@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! <n...@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" <rberg...@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!" <n...@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" <rberg...@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 Wheel
Re: LTS release or not
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" <rberg...@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!" <n...@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" <rberg...@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" <rwhee...@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 >>>>> <rwhee...@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 >>>&g
Re: LTS release or not
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
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"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 >> 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: rwhee...@artifact-software.com >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >> > > >-- >Ron Wheeler >President >Artifact Software Inc >email: rwhee...@artifact-software.com >skype: ronaldmwheeler >phone: 866-970-2435, ext 102 >
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!" <n...@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" <rberg...@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" <rwhee...@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 >>>> <rwhee...@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 >
Re: LTS release or not
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, ilyawrote: > > 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
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" <rberg...@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" <rwhee...@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 <rwhee...@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:1
Re: LTS release or not
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 Moserwrote: > >> >> 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
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 Wheelerwrote: > 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: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > -- Daan
Re: LTS release or not
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" <daan.hoogl...@gmail.com> > To: "dev" <dev@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! <n...@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" <daan.hoogl...@gmail.com> >> > To: "dev" <dev@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 <m...@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
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" <daan.hoogl...@gmail.com> > To: "dev" <dev@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 <m...@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
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! <n...@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" <daan.hoogl...@gmail.com> > > To: "dev" <dev@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 <m...@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
On Mon, Jan 11, 2016 at 7:58 AM, Rene Moserwrote: > >> * 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
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 <run...@gmail.com> wrote: > > > On Jan 11, 2016, at 2:41 PM, Nux! <n...@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" <daan.hoogl...@gmail.com> > >> To: "dev" <dev@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! <n...@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" <daan.hoogl...@gmail.com> > >>>> To: "dev" <dev@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 <m...@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
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
> On Jan 11, 2016, at 2:41 PM, Nux! <n...@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" <daan.hoogl...@gmail.com> >> To: "dev" <dev@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! <n...@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" <daan.hoogl...@gmail.com> >>>> To: "dev" <dev@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 <m...@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
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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: LTS release or not
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" <run...@gmail.com> wrote: > >> On Jan 11, 2016, at 2:41 PM, Nux! <n...@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" <daan.hoogl...@gmail.com> >>> To: "dev" <dev@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! <n...@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" <daan.hoogl...@gmail.com> >>>>> To: "dev" <dev@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 <m...@renemoser.net> wrote: >>>>> >>>>>>>>
Re: LTS release or not
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
thanks Remi, I think I we agree. On Mon, Jan 11, 2016 at 4:16 PM, Remi Bergsma <rberg...@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" <run...@gmail.com> wrote: > > > > >> On Jan 11, 2016, at 2:41 PM, Nux! <n...@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" <daan.hoogl...@gmail.com> > >>> To: "dev" <dev@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! <n...@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 technolo
Re: LTS release or not
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"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
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
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 Malheirowrote: > +1 > Em 9 de jan de 2016 8:55 PM, "Rene Moser" 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 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> wrote: > >> +1 >> Em 9 de jan de 2016 8:55 PM, "Rene Moser" 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
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é >
Re: LTS release or not
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
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
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
On Sun, Jan 10, 2016 at 10:27 PM, Rene Moserwrote: > > 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