I also think that the PR https://github.com/apache/geode/pull/2818, or something that fixes this race, should make it into the release
On Fri, Nov 9, 2018 at 8:59 AM Jason Huynh <jhu...@pivotal.io> wrote: > I just merged a change last night for GEODE-5884 that I think should make > it into the release. > > On Thu, Nov 8, 2018 at 10:33 AM Anthony Baker <aba...@pivotal.io> wrote: > >> I’m working on a review of LICENSE and NOTICE. Looks like a few things >> slipped in that need to be declared. >> >> Anthony >> >> >> > On Nov 2, 2018, at 12:42 PM, Bruce Schuchardt <bschucha...@pivotal.io> >> wrote: >> > >> > Fixes for PRClientServerRegionFunctionExecutionDUnitTest and >> CreateAsyncEventQueueCommandDUnitTest have been pushed to develop. >> > >> > >> > On 11/2/18 11:05 AM, Alexander Murmann wrote: >> >> Hi Ryan, >> >> >> >> I am currently waiting for the failing DUnit tests to pass and then >> plan to >> >> cut the release branch. Does it work for you if the fixes for >> GEODE-5972 >> >> would be merged to the branch after it has been cut? >> >> >> >> On Fri, Nov 2, 2018 at 9:57 AM Ryan McMahon <rmcma...@pivotal.io> >> wrote: >> >> >> >>> Bill Burcham and I have been working on a data inconsistency issue >> which >> >>> involves a lost event across WAN sites during rebalance on the >> originating >> >>> site. We are currently performing root cause analysis. Below is a >> Geode >> >>> ticket which we will update with more details as we learn more. >> >>> >> >>> https://issues.apache.org/jira/browse/GEODE-5972 >> >>> >> >>> On Thu, Nov 1, 2018 at 5:23 PM Ernest Burghardt < >> eburgha...@pivotal.io> >> >>> wrote: >> >>> >> >>>> and PR 390 has been approved and merged >> >>>> >> >>>> On Thu, Nov 1, 2018 at 5:10 PM Ernest Burghardt < >> eburgha...@pivotal.io> >> >>>> wrote: >> >>>> >> >>>>> geode-native fixes are in >> >>>> https://github.com/apache/geode-native/pull/390 >> >>>>> On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker <aba...@pivotal.io> >> >>> wrote: >> >>>>>> The geode-native source headers I mentioned in [1] need to be >> cleaned >> >>>> up. >> >>>>>> Anthony >> >>>>>> >> >>>>>> [1] >> >>>>>> >> >>> >> https://lists.apache.org/thread.html/8c9da19d7c0ef0149b1ed79bf0cecde38f17a854ecfa0f0a42f1ff0b@%3Cdev.geode.apache.org%3E >> >>>>>>> On Nov 1, 2018, at 2:01 PM, Bruce Schuchardt < >> >>> bschucha...@pivotal.io> >> >>>>>> wrote: >> >>>>>>> This PR has been merged to develop >> >>>>>>> >> >>>>>>> >> >>>>>>> On 11/1/18 1:35 PM, Bruce Schuchardt wrote: >> >>>>>>>> I would like to get this PR in the release: >> >>>>>> https://github.com/apache/geode/pull/2757 >> >>>>>>>> I'm testing the merge to develop now >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 11/1/18 1:18 PM, Sai Boorlagadda wrote: >> >>>>>>>>> Sure! agree that we should hold the releases unless there is a >> >>>>>>>>> critical issue. >> >>>>>>>>> >> >>>>>>>>> This is not a gating issue and the code is already committed to >> >>>>>> develop. >> >>>>>>>>> Sai >> >>>>>>>>> >> >>>>>>>>> On Thu, Nov 1, 2018 at 1:03 PM Alexander Murmann < >> >>>> amurm...@pivotal.io >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> In the spirit of the previously discussed timed releases, we >> >>> should >> >>>>>> only >> >>>>>>>>>> hold cutting the release for critical issues, that for some >> >>> reason >> >>>>>> (not >> >>>>>>>>>> sure how that might be) should not be fixed after the branch >> has >> >>>>>> been cut. >> >>>>>>>>>> Waiting for features leads us down the slippery slope we are >> >>> trying >> >>>>>> to >> >>>>>>>>>> avoid by having timed releases. Does that make sense? >> >>>>>>>>>> >> >>>>>>>>>> On Thu, Nov 1, 2018 at 12:45 PM Sai Boorlagadda < >> >>>>>> sai.boorlaga...@gmail.com >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> I would like to resolve GEODE-5338 as it is currently waiting >> >>> for >> >>>>>>>>>>> doc update. >> >>>>>>>>>>> >> >>>>>>>>>>> Sai >> >>>>>>>>>>> >> >>>>>>>>>>> On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann < >> >>>>>> amurm...@pivotal.io> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Hi everyone, >> >>>>>>>>>>>> >> >>>>>>>>>>>> It's time to cut the release branch, since we are moving to >> >>> time >> >>>>>> based >> >>>>>>>>>>>> releases. Are there any reasons why a release branch should >> not >> >>>> be >> >>>>>> cut >> >>>>>>>>>> as >> >>>>>>>>>>>> soon as possible? >> >>>>>>>>>>>> >> >>>>>> >> > >> >>
