PR 3947 appears to be against develop.  Looking for a PR against 
release/1.10.0...

> On Aug 19, 2019, at 1:50 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote:
> 
> Unfortunately the code I'm working with went through some refactoring after 
> the 1.10.0 branch was cut.  A PR based on release/1.10.0 membership changes 
> can't go through a PR pipeline because it won't compile once the changes are 
> merged to develop.
> 
> https://github.com/apache/geode/pull/3947/checks?check_run_id=197482052
> 
> So, I have a branch based on release/1.10.0 that could be merged there but 
> there's no way to test it via Concourse.
> 
> On 8/19/19 9:44 AM, Owen Nichols wrote:
>> Hi Bruce, unfortunately 8e9b04470264983d0aa1c7900f6e9be2374549d9 does not 
>> cherry-pick cleanly into release/1.10.0.  Can you please open a PR against 
>> release/1.10.0?
>> 
>> -Owen
>> 
>>> On Aug 19, 2019, at 9:16 AM, Kirk Lund <kl...@apache.org> wrote:
>>> 
>>> +1
>>> 
>>> On Mon, Aug 19, 2019 at 8:29 AM Alexander Murmann <amurm...@apache.org>
>>> wrote:
>>> 
>>>> +1
>>>> 
>>>> it's a regression in 1.10 and a serious problem.
>>>> 
>>>> On Mon, Aug 19, 2019 at 7:38 AM Bruce Schuchardt <bschucha...@pivotal.io>
>>>> wrote:
>>>> 
>>>>> It sounds like Udo is okay with this now.  Any other concerns?
>>>>> 
>>>>> On 8/17/19 2:07 AM, Owen Nichols wrote:
>>>>>> On Aug 15, 2019, at 2:09 PM, Bruce Schuchardt<bschucha...@pivotal.io>
>>>>> wrote:
>>>>>> This is a fix for a problem where a member that has lost quorum does
>>>> not
>>>>> detect it and does not shut down.  The fix is small and has been
>>>>> extensively tested.  The fix also addresses the possibility of a member
>>>>> being kicked out of the cluster when it is only late in delivering a
>>>>> heartbeat (i.e., no availability check performed).
>>>>>> SHA: 8e9b04470264983d0aa1c7900f6e9be2374549d9

Reply via email to