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