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? >> >>>>>> >> >> >> > >> >>
