geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <>
Subject Re: [DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable
Date Wed, 28 Aug 2019 21:12:21 GMT
Fundamentally I also don't have a problem with cherry-picking fixes to a 
potential release candidate. My concern is that the amount of fixes that 
were cherry-picked.

I also believe that "stabilizing" a release does have some 
cherry-picking, BUT the amount of stabilization that we have to apply 
has to be within reason and control.

I also understand that there are fixes that we want to include that are 
critical. BUT if it takes a month (from cutting to generating an RC) to 
get close to releasing, indicates that whatever is in develop is NOT 
stable. There were fixes that were included and the cause of the issues 
was "due to a recent commit SHA-- XXXX". Which means most likely the 
rigor to review and test said bug/issue was not effectively tested.

Finding issues with maps that should have been concurrent maps and lead 
memory leaks are distressing. Now there we have code that has been 
refactored that we prefer not to release. If we don't want to release 
it, why is it in the main develop branch. Imo, only code THAT CAN BE 
RELEASED should ever make it to the main branch.

Maybe I am the problem here (again).... Maybe it is I that is concerned 
with the quality that is being committed and then glossed over with, it 
is ok, we can fix any resulting issues coming from that.

If everybody is happy to release 1.10, then so be it... here is my +0.

But I don't think this approach of cutting a release branch and then 
effectively having to maintain to development branches and what commits 
are applied to the correct branches is in any way maintainable..


On 8/27/19 11:56 AM, Bruce Schuchardt wrote:
> +1 for going ahead with the current release/1.10
> On 8/27/19 11:31 AM, Dan Smith wrote:
>> +1 to creating RC1 with the current release/1.10 branch this week.
>> I don't see a fundamental problem with cherry-picking some targeted and
>> tested fixes to release/1.10, based on our assessment of the risk to
>> customers vs. the risk of destabilizing the branch. I think 
>> release/1.10 is
>> in a good state, and we should go ahead with the release.
>> -Dan
>> On Tue, Aug 27, 2019 at 9:28 AM Bruce Schuchardt 
>> <>
>> wrote:
>>> The "develop" branch has a refactoring of membership code that should
>>> not be included in 1.10.  I waited until the release branch was cut to
>>> push these changes.
>>> On 8/26/19 4:06 PM, Udo Kohlmeyer wrote:
>>>> Hi there Apache Geode devs,
>>>> It has been some weeks since the proposed 1.10 release was cut. We've
>>>> gone through a few cycles where we keep on submitting "please include
>>>> ticket GEODE-XXX" because it is critical and will break the system.
>>>> WHICH in reality tells me that current develop is broken and unstable.
>>>> I'm going to suggest that we abandon the current 1.10 release branch.
>>>> I cannot shake the feeling that our continuous cherry picking into a
>>>> branch will result in either the branch becoming unmaintainable, given
>>>> we have only select fixes in the branch OR we end up with a branch
>>>> that is more stable than our current development branch, which would
>>>> result in us having to rebase the develop branch onto the 1.10 branch.
>>>> I propose that once we see the pipeline is clean and green for a solid
>>>> we then again attempt to cut 1.10 branch.
>>>> We CANNOT continue adding to a branch in order to stabilize it.. It
>>>> just means the branch we cut from is unstable. If we cannot cut a
>>>> branch from develop without having to have weeks of stabilization
>>>> cycles, then our main branch is broken...
>>>> Either way, not a good spot to be in.
>>>> Thoughts?
>>>> --Udo

View raw message