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