Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I'm working on this right now.. Will submit a PR for GEODE-7531 and GEODE-7159 (it is the similar change than 7531) shortly. --Udo On 12/16/19 2:45 PM, Owen Nichols wrote: Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting it…by the end of this week if possible? > On Dec 11, 2019, at 4:19 PM, Mark Hanson wrote: > > Hi All, > > It does not look like we have an assignee for GEODE-7531. Any

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Hi All, It does not look like we have an assignee for GEODE-7531. Any takers? Thanks, Mark > On Dec 4, 2019, at 2:35 PM, Mark Hanson wrote: > > So, outstanding issues that I see right now are > > GEODE-7531 > GEODE-7537 > GEODE-7538 > > Thanks, > Mark > >> On Dec 4, 2019, at 2:11 PM, John

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I had a side conversation with John. I created a proposal in a separate and a JIRA (GEODE-7555) for what I think is a good long term solution to the issues STDG had mocking the Geode API. In the short term, I'm fine with whatever we decide we should do to support STDG. -Dan On Thu, Dec 5, 2019

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Trying to get a conclusion out of it: - The SDG/STDG to address the issue by changing the code on its part - Create JIRA ticket for the issue raised. And prioritize/work the issue in coming GEODE release. -Anil. On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols wrote: > > On Dec 4, 2019, at 10:09

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

> On Dec 4, 2019, at 10:09 PM, Jacob Barrett wrote: > > I think we can tone down the inflammatory statements Jake, thank you for speaking up, I felt the same way but wasn’t sure how to say it. This might be a good opportunity for all of us to review the

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

+1 to what Jake said. -Dan On Wed, Dec 4, 2019 at 11:32 PM Owen Nichols wrote: > +1 for a short-term solution in 1.11 while we discuss a more complete > proposal for 1.12 > > On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett wrote: > > > I think we can tone down the inflammatory statements. It is

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

+1 for a short-term solution in 1.11 while we discuss a more complete proposal for 1.12 On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett wrote: > I think we can tone down the inflammatory statements. It is well > established that, like any legacy code base, Geode has issues. One of them > is a

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I think we can tone down the inflammatory statements. It is well established that, like any legacy code base, Geode has issues. One of them is a less than ideal set of APIs for certain tasks. Whatever the issues were in the past with getting APIs adjusted to suit the SDG project should be left

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

If you must know, there are important test cases in both SBDG and SSDG to be able to register (and subsequently unregister) the "mock" Pool with the PoolManager, which unfortunately is a consequence of the SDG PoolFactoryBean's design being reliant on the PoolManager (to resolve the Pool), and to

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

@udo, if one needs to use a strong word like 'offender', then the offender is the one using an internal API. Geode is under no obligation to maintain or "fix" these for any project. Is there a Jira, github issue, or pull-request to promote the internal class to the public space? Is there a

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

@Dan, I will add my -1 to this. I understand your argument of "let's solve the problem by removing  the offender". But in reality who is the offender? Is it the one class that is using an "internal" api OR is it the implementation itself that is to tightly coupled that extending it is

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

> > Quite frankly the reasons STDG (or dependent projects downstream like SDG, > SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point > articulated in the description of GEODE-753. > What bothers me here is not your suggestions in GEODE-1753, but the fact that you are vetoing

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

See comment [1] on ticket, GEODE-7531 [2]. Quite frankly the reasons STDG (or

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

On Wed, Dec 4, 2019 at 2:11 PM John Blum wrote: > This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11 > (and all tests pass), as I indicated above in my origin +0 vote. > > This is a definitive problem for SBDG when using STDG to mock Apache Geode > resources/objects,

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

So, outstanding issues that I see right now are GEODE-7531 GEODE-7537 GEODE-7538 Thanks, Mark > On Dec 4, 2019, at 2:11 PM, John Blum wrote: > > This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11 > (and all tests pass), as I indicated above in my origin +0 vote. > >

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11 (and all tests pass), as I indicated above in my origin +0 vote. This is a definitive problem for SBDG when using STDG to mock Apache Geode resources/objects, which is caused by GEODE-7531. Either way, the design/code

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

On Wed, Dec 4, 2019 at 11:16 AM John Blum wrote: > I am changing my vote to -1! > > I have filed GEODE-7531 > [1], > which is a serious blocking issue for all things *Spring* for Apache > Geode. This issue alone is currently preventing me from

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Just an update… 1.11.0.RC3 is not going out. We are in a holding pattern on RC4 due to the issue that Lynn mentioned and other issues found. This is another strike against that RC3 release. If the contributors deem the fix necessary ( I assume they would ), we will put in a fix for that as

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

> On Dec 4, 2019, at 9:24 AM, John Blum wrote: > > Anyway, it because Apache Geode's public API is broken/incomplete > (especially from a framework/tooling perspective, but even an application > perspective in many cases) that SDG must rely on certain (non-protected) > "internal" APIs. It

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I am changing my vote to -1! I have filed GEODE-7531 [1], which is a serious blocking issue for all things *Spring* for Apache Geode. This issue alone is currently preventing me from upgrading *Spring Boot for Apache Geode* (SBDG) to Apache

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Indeed, both dependencies (geode-logging & geode-serialization) are listed as runtime dependencies. *> Is SDG creating its dependencies manually?* I am not quite following your thinking on this question. Of course SDG uses transitive dependencies. SDG must declare direct dependencies on

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

> On Dec 1, 2019, at 2:40 PM, John Blum wrote: > > After some modifications to Spring Data for Apache Geode (Spring Data > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11. > > While I support the modularization effort, I would make it very clear (in > documentation) now

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

+0 After some modifications to Spring Data for Apache Geode (Spring Data Geode; SDG), I was finally able to build SDG with Apache Geode 1.11. While I support the modularization effort, I would make it very clear (in documentation) now that both geode-logging and geode-serialization are required

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

-1 from native client as well, sorry. RC3 mistakenly picked up an unnecessary commit, and left out the crash fix I needed. If you revert commit 5d012199055a9a7657563727f6e26a406b287fc3 and cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes segfault in log message.", native

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

-1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state https://issues.apache.org/jira/browse/GEODE-5307 On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson wrote: > Hello Geode Dev Community, > > This is a release

[VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.11.0.RC3. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback, including the checks you performed. Voting deadline: 11AM PST Monday December 2