cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nux! <...@li.nux.ro>
Subject Re: LTS release or not
Date Tue, 12 Jan 2016 19:43:09 GMT
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" <RBergsma@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!" <nux@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" <RBergsma@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" <rwheeler@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

Mime
View raw message