Re: Exploring using Kotlin for building the "Cluster Management Service"

Hi there Aditya, Thank you for raising this topic. I've been thinking of using Kotlin for a VERY long time now. I believe that Kotlin will provide is with many benefits other than just `non-nullable` fields/parameters but also with immutability. Conciseness of code is another benefit and th

Re: [Proposal] Adding Micrometer to Apache Geode

I agree with Jacob here. Great to see such great strides forward +1 deprecating old Stats APIs It would be good to see the new Micrometer stats have a logical grouping, that makes it easier for users to search for metrics. Does this mean that Geode will now support fully tagged/dimension met

Re: [Proposal] adding a new type of PdxInstance

Darrel, thank you for this. I would like to propose a counter-proposal. Instead of introducing another PDXInstance type, why don't we improve the serialization framework itself? I know my proposal is most likely going to take a little more effort than adding a new type, but I believe it is le

Re: [Proposal] adding a new type of PdxInstance

ose are going to be done based on a sequence of serialized bytes then you really need to understand your serialization code and make sure that "equal" objects always have the same serialized form. On Tue, Jan 15, 2019 at 10:38 AM Udo Kohlmeyer wrote: Darrel, thank you for this. I would

Re: Preventing new build warnings

So, to reduce the number of new warnings, are we then going to standardize on JDK versions? i.e, we only build with JDK 8 build 192 and JDK11 build 03, because changes in JDK can introduce warnings. I'm all for reducing warnings, but they are warnings. Don't think we need to error, or break on

Re: [Proposal] Adding Micrometer to Apache Geode

11:58 AM Dale Emery <mailto:dem...@pivotal.io>> wrote: Hi Udo and all, > On Jan 15, 2019, at 10:06 AM, Udo Kohlmeyer mailto:u...@apache.org>> wrote: > > It would be good to see the new Micrometer stats have a logical grouping, that makes it easier

Re: [Proposal] adding a new type of PdxInstance

zed data is tricky because you need to come up with a equals and hashCode and if those are going to be done based on a sequence of serialized bytes then you really need to understand your serialization code and make sure that "equal" objects always have the same serialized form.

Re: Merging GEODE-6424 into release/1.9.0

+1, Go,Go,GO!! On 2/20/19 12:24, Jacob Barrett wrote: Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 into release/1.9.0? Without it we will have to wait for the next release before we can have meaningful basel

Re: Dependency review for release 1.9.0

I wonder if we should be looking at shaded jars for the extensions. --Udo On 2/28/19 09:47, Charlie Black wrote: Hopefully, we are thinking about classpath of the server and lazily adding these jars only when a feature is turned on. On Thu, Feb 28, 2019 at 9:45 AM Dan Smith wrote: I see tha

Re: [DISCUSS] removal of geode-json module

IMO, I think it would better serve the project if were to remove it completely and replace it with jackson. On 3/15/19 14:06, Bruce Schuchardt wrote: I've removed use of geode-json in non-test code and I'd like to remove it completely and just add a dependency on a org.json package in a Maven

Re: [DISCUSS] TTL setting on WAN

-1, I don't believe this is a feature that we should support. IF a client is experiencing slow WAN replication and users only care about the "latest" data, then maybe the user should use "conflation". With a TTL model, we are messing with our consistency tenet. I'm am NOT in support of a setti

Re: [DISCUSS] TTL setting on WAN

site from going down.  I guess the docs for TTL should make it very clear that it will cause inconsistencies. Conflation does seem like an appropriate thing to try if the same keys are being updated - I'll do some investigation and see why it wasn't appropriate. On 3/20/19 10:51 A

Re: [DISCUSS] Move or remove org.apache.geode.admin

+1 on removing the JMXManager stuff for Geode 2.0 release. But this "hidden" feature, what is that? Is this something that we would like to support or is this something that would be replaced with our existing efforts in the ConfigurationService and Metrics area. On 4/2/19 17:04, Dan Smith wr

Re: GEODE-6662 for 1.9.0

Unless this is a critical issue I'd vote -1 for including this. The process to release 1.9 has already been started and should be closed to anything other than critical CVE's. --Udo On 4/17/19 11:30, Bruce Schuchardt wrote: I'd like to include the fix for this memory leak that Darrel found.

Re: Backwards compatibility issue with JSONFormatter

How did this slip the review process that the signature of a public API was changed? Well done Gester for finding this!! --Udo On 5/14/19 10:40, Dan Smith wrote: I think the changes for GEODE-6327 broke backwards compatibility in JSONFormatter with the change from fromJSON(String jsonString)

Re: [DISCUSS] is it time to make Windows tests gating?

I think we need to make sure our windows tests get to green... If we make them gating then we will never release, but at the time be motivated to fix them, in order to release. Maybe they run once every day... to at least start getting an idea of health On 5/15/19 18:28, Owen Nichols wrote: F

Re: Changing external methods to no longer throw UnsupportedOperationException

+1 to implementing this method. There is no plausible reason NOT to implement this. --Udo On 5/23/19 12:44, Dan Smith wrote: +1 to implementing this method in a minor release. I'm with Jake on this one. Every bug we fix changes the behavior of the product in some small way. This seems like a

Re: [DISCUSS] Criteria for PMC, committers

@Owen Some interesting thoughts and proposals. None of which I think we could easily implement, but some that I would LOVE to have. I also apologize for restating many things that Helena has already said, but it is taking my a long time to craft this email... Jake has raised a concern that I

Re: [DISCUSS] require reviews before merging a PR

Thank you Dan, Some guidance around how we can go about reviewing the code. I want to remind ALL committers..https://www.apache.org/dev/new-committers-guide.html#committer-responsibilities It states "/Each committer has a responsibility to monitor the changes made for potential issues, both

Re: what is the best way to update a geode pull request

I think a single (squashed if required) commit for the start of a PR. ANY changes due to comments should be reflected as separate commits on the PR. Once approved, that PR should squash all commits into 1 commit with a message that describes what was done,etc... In the past I've heard develope

Re: what is the best way to update a geode pull request

ONE. On 5/31/19 14:31, Jacob Barrett wrote: On May 31, 2019, at 2:23 PM, Udo Kohlmeyer wrote: I must be honest, but I am yet to find 1 developer that keeps a list of all changes they want to be refactored separate from the bug/feature code. OR better stated I am yet to find where this was sust

Re: IntelliJ inspect git hooks

@Peter, as I understand that we don't want to at least not to add to the existing pain, BUT I don't know if that any plugin or Intellij can determine if it was made worse. I think just cleaning up the warnings should not be too hard... That way it can be simple reasoning if it has been made wo

Re: IntelliJ inspect git hooks

Boy scouts.. yeah... @kirk has tried a few times to remind people not to add to the crazy... but seemingly it just keeps coming back... So short of, "you've added warnings" and rejecting, this is not going to be easily solved. --Udo On 6/3/19 12:44, Peter Tran wrote: @Udo K

Re: [DISCUSS] require reviews before merging a PR

@Kirk, I totally understand the pain that you speak of. I too agree that every line of changed code should have a test confirming that behavior was not changed. I don't believe that we need to go as far as revoking committer rights and reviewing each committer again, BUT it would be AMAZING th

Re: [DISCUSS] require reviews before merging a PR

ddress the root of the problem (accidental complexity & lack of test coverage) On Wed, Jun 5, 2019 at 11:03 AM Udo Kohlmeyer wrote: @Kirk, I totally understand the pain that you speak of. I too agree that every line of changed code should have a test confirming that behavior was not changed. I don&#

Re: [DISCUSS] changing geode 32-bit counter stats to 64-bit

+1, if the LongAdders have already added and the additional memory usage has already been dealt with, then adding the accessors does not really make a difference anymore. On 6/7/19 13:47, Jacob Barrett wrote: I like this! I’d go ahead and change all the usage of the int methods to the long me

Re: Unnecessary uses of final on local variables

+1 to everything Bill said +1 to what Anthony recommended I think that we in many cases we should not confuse scope with variable reassignment. And we should not confuse variable reassignment with methods that affect change of a local object. Stateful objects don't have to be immutable and

Re: Unnecessary uses of final on local variables

I agree with Darrel, Bill has made some very compelling arguments. I also add my vote of -1 to remove "noisy" final keywords from local variables. I am VERY interested in understanding how the JVM would handle this, as final is a keyword that stops the reassignment of the variable with anoth

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

I know that I'm missing the benefit of physically moving the code from the package into its own module. Could you possibly explain to me what it is? On 6/21/19 07:37, Murtuza Boxwala wrote: I think that’s a really clever way to increment toward splitting geode-core into more modules. I am exc

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

e, if Module A changes, Module B will not recompile, because the dependency guarantees that nothing about Module B could have been affected. On Jun 21, 2019, at 2:14 PM, Udo Kohlmeyer wrote: I know that I'm missing the benefit of physically moving the code from the package into its own modu

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1, Count me in On 6/24/19 13:06, Juan José Ramos wrote: Hey Jake, Sure, I guess we could do a live session if there's enough interest after people have reviewed the proposal. Best regards. On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett wrote: On Jun 24, 2019, at 11:49 AM, Juan José Ramos

Re: [DISCUSS] RFC 0: Lightweight RFC Process

@Dan, Thank you for your first attempt at this. Maybe we should be a rename "Active" to "Completed". "Active" to me means that we are currently working on them, rather having completed them. I don't view these proposals as features that can be toggled on/off (or active/inactive). Also, I di

Re: [DISCUSS] Time to cut Geode 1.10.0?

I don't think we need to wait for this, as there has been no RFC process followed. --Udo On 7/22/19 3:38 PM, Jinmei Liao wrote: Work is still being planned to move the cluster management rest service under an experimental version flag and use a geode property to turn it on/off. I would say we

Re: [DISCUSS] Time to cut Geode 1.10.0?

should be including this work, experimental or otherwise. --Udo On 7/22/19 4:51 PM, Alexander Murmann wrote: Udo, do you mind explaining how the RFC process comes into this? Are you suggesting that we should wait if an RFC had a target release attached? On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer

Re: [DISCUSS] Time to cut Geode 1.10.0?

management service? I saw a [Discuss] thread for it, as well as a proposal at https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer wrote: I don't believe we should be including anything into the Geode release that has no

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

The latest version of SBDG 1.2 is already in RC stage. Which means the dependent Geode version cannot be changed any more. Currently SBDG 1.2 is based on Geode 1.9. This will not change. Patch versions to 1.9 are supported, but not changes to 1.10 or later. THUS, Once SBDG 1.3 (Neuman) is rel

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

ke we shouldn't bother with Geode 1.9.1 then. If I'm misinterpreting what you wrote, let me know. On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer wrote: The latest version of SBDG 1.2 is already in RC stage. Which means the dependent Geode version cannot be changed any more. Currently SBDG

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

@Aaron, is this an existing issue (i.e this was not introduced in a current refactor)? If the answer is anything other that "This will make the system stop working", I would vote: -1 If this is an existing issue and has been around for a while, I think we hold off including this. I think t

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

on July 31 for GEODE-7001. On Tue, Aug 13, 2019 at 6:22 PM Anthony Baker wrote: Given that we’re trying to stabilize the release branch and this fix seems to *help* that I’m in favor of merging it. Anthony On Aug 13, 2019, at 5:32 PM, Udo Kohlmeyer wrote: @Aaron, is this an existing issue

Re: Proposal to Include GEODE-7079 in 1.10.0

Juan, From your explanation, it seems this issue is existing and not critical. Could we possibly hold this for 1.11? --Udo On 8/15/19 5:29 AM, Ju@N wrote: Hello team, I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release 1.10.0. Long story short: a *NullPointerExceptio

Re: Proposal to Include GEODE-7079 in 1.10.0

and the region takes long to recover... you can actually see millions of *NPEs* flooding the member's logs. My two cents anyway, it's up to the community to make the final decision. Cheers. On Thu, Aug 15, 2019 at 5:58 PM Udo Kohlmeyer wrote: Juan, From your explanation, it seems t

Re: Proposal to Include GEODE-7079 in 1.10.0

I’m not sure we are there yet. I think the release branch concept has merit because it allows us to isolate ongoing work from the changes needed for a release. +1 for including GEODE-7079. Anthony On Aug 15, 2019, at 10:51 AM, Udo Kohlmeyer wrote: Seems everyone is in favor or including a

Re: Proposal to Include GEODE-7079 in 1.10.0

of system stability. Also, this is the change, which doesn't seem particularly risky to me. - ConflationKey key = new ConflationKey(gsEvent.getRegion().getFullPath(), + ConflationKey key = new ConflationKey(gsEvent.getRegionPath(), -Dan On Thu, Aug 15, 2019 at 12:23 PM Udo K

Re: Proposal to Include GEODE-7079 in 1.10.0

ConflationKey key = new ConflationKey(gsEvent.getRegion().getFullPath(), + ConflationKey key = new ConflationKey(gsEvent.getRegionPath(), -Dan On Thu, Aug 15, 2019 at 12:23 PM Udo Kohlmeyer wrote: Whilst I agree with "*finish* when we believe the quality of the release branch is sufficie

Re: I propose including the fix for GEODE-3780 in 1.10

Looking at the Geode ticket number, it seems this problem has resurfaced, as it seems to have been addressed in 1.7.0 already. My concern is, do what know WHAT caused it to resurface? Or was this issue always dormant and only recently resurfaced? Without understand why we are seeing "fixed" is

Re: Propose fix for 1.10 release: Export offline data command failed with EntryDestroyedException

+1 to include On 8/16/19 12:43 PM, Eric Shu wrote: Hi, I'd like to include the following commit ( https://gitbox.apache.org/repos/asf?p=geode.git;h=aa33060) into Geode 1.10 release. The commit fixes the issue that a user tries to use export offline data to a snapshot file but failed. This iss

Re: Proposal to include GEODE-7088 and GEODE-7089 in 1.10.0

In order to better understand this request: Is this an existing issue? Why is it more critical to squeeze it into an existing (almost release) version of Apache Geode? What guarantees do we have that this fix makes the application more stable compared to adding another hidden issue, which we

[DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable

Hi there Apache Geode devs, It has been some weeks since the proposed 1.10 release was cut. We've gone through a few cycles where we keep on submitting "please include ticket GEODE-XXX" because it is critical and will break the system. WHICH in reality tells me that current develop is broken a

Re: Proposal to include GEODE-7088 and GEODE-7089 in 1.10.0

dence we need. Thanks, Ryan On Mon, Aug 26, 2019 at 3:17 PM Udo Kohlmeyer wrote: In order to better understand this request: Is this an existing issue? Why is it more critical to squeeze it into an existing (almost release) version of Apache Geode? What guarantees do we have that this fix make

Re: [DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable

with the release. -Dan On Tue, Aug 27, 2019 at 9:28 AM Bruce Schuchardt wrote: The "develop" branch has a refactoring of membership code that should not be included in 1.10.  I waited until the release branch was cut to push these changes. On 8/26/19 4:06 PM, Udo Kohlmeyer wro

Re: [VOTE] Apache Geode 1.9.1 RC1

+1 for a re-vote On 8/28/19 2:42 PM, Kirk Lund wrote: SBDG 1.2 is currently in RC and cannot be changed to depend on Geode 1.10. It must depend on Geode 1.9 or 1.9.1. So if we want to provide the logging fixes for SBDG 1.2 then we must release Geode 1.9.1. Let's open a new vote for releasing G

Re: [VOTE] Apache Geode 1.9.1 RC1

+1 On 8/28/19 5:41 PM, John Blum wrote: +1 On Wed, Aug 28, 2019 at 2:51 PM Dan Smith wrote: I missed this vote email as well - if we reopen the vote I'll cast one. I don't really have much context on why we want a 1.9.1 but I'm happy to double check the bits. One comment on this RC - I noti

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

+1 On 8/29/19 9:51 AM, John Blum wrote: +1 On Thu, Aug 29, 2019 at 9:41 AM Kirk Lund wrote: +1 (just in case my vote counts) On Thu, Aug 29, 2019 at 9:02 AM Kirk Lund wrote: Hello Geode dev community, This is a release candidate for Apache Geode, version 1.9.1.RC1. Thanks to all the com

Re: [VOTE] Apache Geode 1.9.1 RC2

+1 On 8/29/19 5:02 PM, Owen Nichols wrote: Hello Geode dev community, This is a release candidate for Apache Geode, version 1.9.1.RC2. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback. The deadline is 3PM PST Wed, September

Re: [DISCUSS] RFC - Move membership code to a separate gradle sub-project

I've reviewed and commented on the RFC. +1 on the thought / notion of extracting modules. I'm less convinced on the initial extraction of the geode-serialization module and believe some attention is to be given to this, once a decision to convert the serialization to a stand alone module. --

Re: [VOTE] Adding a lucene specific fix to release/1.10.0

-1 I must agree with Owen's analysis. It's a known problem, and it will not cause the system to stop working. Yes, it is a bug and will cause issues with results, BUT it will NOT affect the stability of the system. Which is one of the only reasons we should be adding fixes to an already cut r

Re: [VOTE] Adding a lucene specific fix to release/1.10.0

of the future work towards improving this part of the process rather than having to revert the change due to your minus one? On Thu, Sep 19, 2019 at 1:17 PM Udo Kohlmeyer wrote: -1 I must agree with Owen's analysis. It's a known problem, and it will not cause the system to stop

[DISCUSS] - Cutting of release 1.9.2

Hi there Geode Dev's, I would like to propose a release for Geode 1.9.x that includes https://issues.apache.org/jira/browse/GEODE-7121. This is an issue that is current in the 1.9.x branch, which is used by Spring Data Geode 2.1.10 . This issue

Re: [DISCUSS] - Cutting of release 1.9.2

r SDG 2.2/Moore GAs, which is tentatively scheduled for Monday, Sept. 30th. On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund wrote: Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0? On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer wrote: Hi there Geode Dev's, I wou

War's vs JArs

Hi there Geode Dev, I've just run into an interesting situation where I've realized that since Geode 1.8.0, the maven repository artifacts for geode-web and geode-web-api have changed from type war to jars. Is this something that was intentional? --Udo

Re: War's vs JArs

at I remember - they need to be run within a geode server/locator. -Dan On Tue, Sep 24, 2019 at 10:55 AM Udo Kohlmeyer wrote: Hi there Geode Dev, I've just run into an interesting situation where I've realized that since Geode 1.8.0, the maven repository artifacts for geode-web and geo

Re: [VOTE] Apache Geode 1.10.0.RC2

Given that 1.8, 1.9 are currently publishing the jar's to the maven central, instead of wars, I can only assume that 1.10 would do the same. Also, given that everyone is surprised by this, means that we have not address this issue. Until we can confirm that we would publish war files instead

Re: [VOTE] Apache Geode 1.10.0.RC2

bout this issue? Since this is not a new issue in 1.10 (as you say, it is the case in 1.8, 1.9, 1.9.1) is it really a -1 ? On Tue, Sep 24, 2019 at 12:01 PM Udo Kohlmeyer wrote: Given that 1.8, 1.9 are currently publishing the jar's to the maven central, instead of wars, I can only assume th

Re: [VOTE] Apache Geode 1.10.0.RC2

ave to fix this issue for 1.9.x, so 1.9.2 will require this fix. --Udo On 9/24/19 1:21 PM, Robert Houghton wrote: Udo, is there a Jira about this issue? Since this is not a new issue in 1.10 (as you say, it is the case in 1.8, 1.9, 1.9.1) is it really a -1 ? On Tue, Sep 24, 2019 at 12:01 PM Udo K

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Maybe the better question is, WHY are we publishing geode-web and geode-web-api. Pulse, from what I remember, could be a standalone deployment. At least that is what I remember. Most likely an oversight... --Udo On 9/24/19 3:38 PM, Robert Houghton wrote: The geode-pulse module also builds

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Seems these should have been Jars all along... On 9/24/19 8:09 PM, Jacob Barrett wrote: Why publish them as WAR files at all? As they are currently packaged they can't be deployed in just any J2EE web container because they lack all the dependencies. Sure they look like WAR files internally bu

Re: [DISCUSS] GEODE-7241 - make Jar not War?

44 PM, Udo Kohlmeyer wrote: Maybe the better question is, WHY are we publishing geode-web and geode-web-api. Pulse, from what I remember, could be a standalone deployment. At least that is what I remember. Most likely an oversight... --Udo On 9/24/19 3:38 PM, Robert Houghton wrote: The geode-

Re: [DISCUSS] GEODE-7241 - make Jar not War?

seems like the best option for now. Anthony On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer wrote: @Anthony. Ticket was updated.. In a nutshell, to run integration tests, using the REST endpoints, requires the starting of the server with and embedded web-server. As all tests run on dependency

Re: [DISCUSS] - Cutting of release 1.9.2

It seems there is consensus to cut a 1.9.2 release to include GEODE-7121. --Udo On 9/20/19 3:34 PM, Jens Deppe wrote: +1 for creating a 1.9.2 release with this fix. On Fri, Sep 20, 2019 at 2:00 PM Udo Kohlmeyer wrote: John, thank you! You are correct, not sure what I was thinking.. Geode

Re: [DISCUSS] GEODE-7241 - make Jar not War?

excited about a new 1.8 patch release but I’m open to hearing your ideas :-) Anthony On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer wrote: So it seems there is consensus around jar vs war. WAR's win by nose. (until we can find a more creative way to expose said artifacts) That said, do we ne

Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019, at 11:46 AM, Udo Kohlmeyer wrote: So it seems there is consensus around jar vs war. WAR's win by nose. (until we can find a more creative way to expose said artifacts) That said, do we need to start another thread about fixing 1.8.x or 1.9.x? I'm already considering pro

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

I don't know enough about the limitations between the two libraries. BUT I would prefer, like Kirk, some consistency w.r.t. implementations. Also, this is for testing, so I'm really questioning are we going to be pushing the boundaries of what this library can do. In addition, if there would b

Cutting Geode 1.9.2

Hi there Geode Dev's, There seems to be consensus on cutting Geode 1.9.2. https://lists.apache.org/thread.html/9b5f5c58e1b298d9d0ca870a0deec06f7344a60809790c75a5f68bfa@%3Cdev.geode.apache.org%3E Would there be any willing candidates who would raise their hand to shepherd this release? Maybe s

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Robert, I think the consensus is that WAR is the correct option. So unless someone objects, GEODE-7241 is a GO! --Udo On 9/30/19 10:58 AM, Robert Houghton wrote: I am unclear on the consensus of this thread. On Wed, Sep 25, 2019 at 12:55 PM John Blum wrote: @Jake - Ah, indeed it was https

Re: [Announce] Release branch 1.9.2 created

+1 to adding GEODE-7079. I believe this will improve the overall stability of what is already being targeted for the 1.9.2 release. --Udo On 10/4/19 10:12 AM, Juan José Ramos wrote: Hello Jens, Thanks for your detailed email. That said, I'm aware of the fact that the main purpose of 1.9.2 rel

Re: [Announce] Release branch 1.9.2 created

Hi there Owen, Thank you for pointing out the missed process. @Jens, I think the majority of the GEODE tickets listed are related to the AEQ pause feature. If so, it might be best to group them, in order to best gauge which tickets need to be discussed to be included in the release. --Udo

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

Hi there Owen, I apologize if it is not clear. GEODE-7241 is a regression where the published artifact "geode-web" and "geode-web-api" were published as jars and not wars. NOW, why is it critical for 1.9.x... Well, the answer is fairly short. In Spring Data Geode, there is an ability to star

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

). Thanks for clarifying what is at stake. +1 for including both fixes On Oct 7, 2019, at 4:50 PM, Udo Kohlmeyer wrote: Hi there Owen, I apologize if it is not clear. GEODE-7241 is a regression where the published artifact "geode-web" and "geode-web-api" were published as jar

Re: [VOTE] Apache Geode 1.9.2.RC1

Hi there Owen, Whilst I share your concern of consistence, the Geode user community did not notice that the artifacts changed from war -> jar (GEODE-7241). The Spring Data Geode project is currently the only downstream project which discovered this regression. As Spring Data Geode 2.2 will n

Re: [DISCUSS] Blocking merge button in PR

I must agree with @Karen here.. All committers are trusted to do the right thing. One of those things is to commit (or not commit) PR's. Now we are discussing disabling the button when tests are failing. Why stop there? Why not, that the submitter of the said commit does not get to merge the

Re: [DISCUSS] Blocking merge button in PR

l the extra defensive red tape will eventually inhibit the project. That is how all bureaucracy starts.. small innocent.. and eventually it becomes this heavy beast that no-one can master. --Udo On 10/21/19 10:30 AM, Robert Houghton wrote: @Udo Kohlmeyer <mailto:ukohlme...@pivotal.io&g

Re: [DISCUSS] Blocking merge button in PR

er if we feel a strong sense of community, we might be ok with an anyone-can-revert policy. A revert does not have to imply shaming... On Oct 21, 2019, at 10:30 AM, Robert Houghton wrote: @Udo Kohlmeyer What, if anything, do you propose we do to help keep our project building and running cl

Re: [DISCUSS] Blocking merge button in PR

(via human or automated means), is this an education problem we can solve? On Mon, Oct 21, 2019 at 10:18 AM Udo Kohlmeyer wrote: I must agree with @Karen here.. All committers are trusted to do the right thing. One of those things is to commit (or not commit) PR's. Now we are discussing dis

Re: [VOTE] Apache Geode 1.9.2.RC1

+1, Checked that WAR's are generated for geode-web and geode-web-api. Also ran set of examples and tests from Spring Data Geode (Moore), to confirm that it has not broken functionality. --Udo On 10/21/19 8:20 AM, Jens Deppe wrote: Since the deadline has expired without enough votes, I am go

Re: [DISCUSS] Blocking merge button in PR

@owen, whilst you are technically correct, THIS is not the process that we as a Geode committer community have agreed upon. The commit process within GEODE is to raise a PR. Simple... --Udo On 10/22/19 9:53 AM, Owen Nichols wrote: This discussion has revolved around the assumption that all c

Re: [VOTE] Apache Geode 1.9.2.RC1

@Jens, @Owen, With the discussion to cut a 1.11 release, I think we are safe in saying that change can make it into that release and a 1.10.1 is not required. UNLESS there is another third part This fix was only included in the 1.9.2 release, because this is the version that Spring Data Geod

[DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi there fellow Apache Geode Devs, We would like to propose the upgrade of the Spring libraries within Geode Project. Currently the project is using Spring 4, which is EOL Q1 2020. The link the proposal can be found here

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

remains in one single place. Cheers. [1]: https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process On Wed, Oct 30, 2019 at 5:54 PM Udo Kohlmeyer wrote: Hi there fellow Apache Geode Devs, We would like to propose the upgrade of the Spring libraries within Geode Project

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Sorry, To clarify... When we change the Spring version we would be looking at looking to use the latest version and it's associated BOM. That might be inclusive of other Spring project upgrades. --Udo On 10/30/19 1:35 PM, Nabarun Nag wrote: Hi Udo, Maven has the latest as 5.2.0.RELEASE as t

Re: [DISCUSS] is overriding a PR check ever justified?

+1 to override in extreme circumstances -1 to have an override flag with simple access for the common man. I think we need a "break glass" override.. but not something that is easily accessible. The 99.9% case has to go through the current process and constraints... BUT I think we ne

Re: [DISCUSS] is overriding a PR check ever justified?

You are correct... Break glass is a sign that whatever needed to be done, was not going to work using the prescribed approach.. I see this "break glass" as a special handshake or someone with more "authority" needs to be agree with this... but given there is not "someone with more authority" i

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

, Oct 30, 2019 at 1:39 PM Udo Kohlmeyer wrote: Sorry, To clarify... When we change the Spring version we would be looking at looking to use the latest version and it's associated BOM. That might be inclusive of other Spring project upgrades. --Udo On 10/30/19 1:35 PM, Nabarun Nag wrot

Adding GEODE-7412 to 1.11 release

Hi there Geode Dev, I would like to request that we add https://issues.apache.org/jira/browse/GEODE-7412 to the 1.11 release. This change is a build change that has crept in since 1.8. The issue that is to be fixed is that the web archive, (

Re: Adding GEODE-7412 to 1.11 release

ODE-7241> ? On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer wrote: Hi there Geode Dev, I would like to request that we add https://issues.apache.org/jira/browse/GEODE-7412 <https://issues.apache.org/jira/browse/GEODE-7412> to the 1.11 release. This change is a build change that has crept

Re: Adding GEODE-7412 to 1.11 release

t 12:54 PM, Udo Kohlmeyer wrote: @Owen, I did not specifically check all web archives for this issue. Yes, I *should* have been caught in that ticket. On 11/8/19 11:03 AM, Owen Nichols wrote: I’m curious, how was this missed in https://issues.apache.org/jira/browse/GEODE-72

Re: Propose adding GEODE-7400 fix to 1.11 release

+1 On 11/11/19 9:41 AM, Kirk Lund wrote: I propose merging the fix for GEODE-7400 (merged to develop today) to the 1.11 release branch. My fix for GEODE-7330 (merged to develop in late October) introduced GEODE-7400 which is the potential for RejectedExecutionException to be thrown within Feder

Re: Quick turnaround needed, feedback on this DRAFT Nov board report

+1 Haven't double checked the numbers, but the rest LGTM On 11/13/19 9:49 AM, Karen Miller wrote: Draft board report for November 2019. Submitting in 2 hours! Quick feedback, please! ## Description: The mission of Apache Geode is the creation and maintenance of software related to a data man

Re: Adding GEODE-7412 to 1.11 release

ov 8, 2019 at 12:56 PM Owen Nichols wrote: +1 On Nov 8, 2019, at 12:54 PM, Udo Kohlmeyer wrote: @Owen, I did not specifically check all web archives for this issue. Yes, I *should* have been caught in that ticket. On 11/8/19 11:03 AM, Owen Nichols wrote: I’m curious, how was this missed

Re: Odg: gateway sender queue

+1, I love that idea... Problem is that we don't have sufficient auditing around managment/Operational tasks. What happens if this task is run on an active cluster? Without proper auditing and possibly some notion on WHAT data was purged, this could open the product up for many head-aches.. i.

Re: Odg: gateway sender queue

In addition... making is default has bigger consequences that we have not thought about.. e.g if you purge an existing queue on start up.. is this the start up of the server node / GS Queue? Given that we have shared-nothing architecture, purging *should* only be local and not cluster-wide...

  1   2   3   4   5   6   >