Re: Review Request 42075: GEODE-771: CI Failure: PdxGroupByPartitionedQueryDUnitTest.testCompactRangeIndex failed with AssertionFailedError

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42075/#review113502 --- Ship it! Ship It! - Hitesh Khamesra On Jan. 8, 2016, 6:19

Re: enabling network partition detection by default

The default member-timeout is 5 seconds. For an unpredictable network or a system with GC pauses we might want to use a longer member-timeout in deployment. Network-partition-detection isn't involved in that though - it's just normal failure detection. Where network-partition-detection

Re: enabling network partition detection by default

My understanding is that by default PDX does not use a disk store. You need to set "pdx-persistent" to true. The default is false. But if you have any persistence in a member and use pdx you will get an exception if you don't set pdx-persistent to true. On Thu, Jan 7, 2016 at 1:31 PM, Michael

Re: Review Request 41836: GEODE-719: Add error logs while cache.xml processing

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41836/#review113503 ---

Re: releaseType?

+1 What is the Apache way? If there are no strict guidelines as to how Apache projects are supposed to release, then I vote we an existing "standard". --Udo On 1/8/16 10:48 AM, John Blum wrote: For clarification, the "RELEASE" version qualifier is only used for the final GA

Re: releaseType?

> Also, I don’t see a need to do M? or RC? releases before this initial release. I think we could have called this release M1 (our first milestone of removing olg jgroups and cleanup) rather than alpha1. But it probably is too late to change that now. On Fri, Jan 8, 2016 at 10:48 AM, John Blum

Commit message format

Reminder that we're supposed to be using formatting like the following for commit messages (if I'm wrong, please correct this)... GEODE-nn: Capitalized, 50 chars or less summary More detailed explanation with linefeeds to wrap at 72 characters after a blank line following the summary. Further

Re: releaseType?

In Spring, the releaseType (qualifier) is always (BUILD-)SNAPSHOT unless it is a release (M1, M2, ..., RC1, ... RELEASE (GA)). When a particular version ends, for instance when 1.0.0.RELASE goes GA, the version/releaseType switches to 1.1.0.(BUILD-)SNAPSHOT and a 1.0.x branch is created to

Re: Open pull requests

True, the graph definitely, but the commit messages, not so much. On Fri, Jan 8, 2016 at 9:38 AM, Kirk Lund wrote: > That's probably caused by the fact that many of us are just learning git. > > -Kirk > > > On Fri, Jan 8, 2016 at 9:34 AM, John Blum wrote: >

Re: enabling network partition detection by default

I don't like the idea of having two properties file as it will be confusing to both new and existing users. Even if we decide to go with two files, I think we should strive to keep things simpler for new users, say by have a "old-defaults.properties" file which the existing users can use. On

Re: Review Request 39012: GEODE-106: Invalidate operation fails with IndexMaintenanceException with underlying java.lang.ArrayIndexOutOfBoundsException: 1

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39012/#review113521 ---

Re: releaseType?

+1 I agree to follow the Spring model (Mx, RCx, RELEASE), which will be inline with following the Maven publishing guidelines. As for using M1, M2, M3 vs ALPHA, BETA for other Apache projects, I took a quick look and seems to be divided. We haven't released yet, so not too late right? Whatever

Re: Review Request 39012: GEODE-106: Invalidate operation fails with IndexMaintenanceException with underlying java.lang.ArrayIndexOutOfBoundsException: 1

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39012/#review113526 ---

Re: enabling network partition detection by default

Persistence engineers, please correct me if I'm wrong: The diskStores record membership view information and use this to figure out which store is most up-to-date. When there is a split-brain there's no way to know which is more recent. Le 1/8/2016 8:34 AM, Michael Stolz a écrit : I'm not

Re: enabling network partition detection by default

I don't think I got my point across correctly. If we change defaults we need to document that, of course, and not just in our 1000+ page manual because that will not be read soon enough to avoid problems from the changed defaults. We definitely need that to appear in the release notes. I think

Re: Open pull requests

The way our github integration is set up with apache, only the original submitter of the PR can close the PR through the github API. Committers can only close PRs by committing with "Closes #XX" in the message or merging in the PR without rebasing. -Dan On Fri, Jan 8, 2016 at 9:46 AM, John Blum

Re: Open pull requests

The latter confuses me. If I want to add "Closes #XX" to the PR's commit message then I have to do a rebase before committing. How would merging it without rebasing close the PR? Isn't that what I was doing that then resulted in me having to issue an empty commit with "Closes #XX" after the fact?

Re: Open pull requests

Well, if we still have some remaining PR's open that are not being closed properly by the merges, let's ask asf infra to close them, no big deal. On Fri, Jan 8, 2016 at 12:19 PM, Dan Smith wrote: > You can either > A) rebase and add the "Closes #XX" message. In this case

Re: Can we tweak svngit2jira to ignore feature branches ?

Yep. I went though *lots* of tickets last night and ran into this all over. Anthony > On Jan 8, 2016, at 5:22 PM, Jacob Barrett wrote: > > ++1 > > On Fri, Jan 8, 2016 at 5:06 PM Dan Smith wrote: > >> ++1 >> >> We're currently getting lots of silly

Re: Can we change JIRA notifications?

+1 On Fri, Jan 8, 2016 at 5:26 PM, Jacob Barrett wrote: > In line with William's request to limit the JIRA emails on feature > branches, can we change the notification model for all JIRAs to something > less frequent. > > Only have the initial create notification go to the

Can we tweak svngit2jira to ignore feature branches ?

The idea here is that feature branches would not update the JIRA tickets anymore, just when they get merged to develop, release or master an entry would be added to the JIRA comments. If we're ok with that I can go ahead and open that ticket with INFRA. Thanks! -- William Markito Oliveira --

Can we change JIRA notifications?

In line with William's request to limit the JIRA emails on feature branches, can we change the notification model for all JIRAs to something less frequent. Only have the initial create notification go to the entire group. After that only those "watching" the JIRA will get notifications. If you

Re: Review Request 41557: GEODE-643: improve UnsafeMemoryChunk coverage

> On Dec. 18, 2015, 11:35 a.m., Anthony Baker wrote: > > I suggest deleting dead code rather than commenting it out. Ok, I have removed the dead code. - Darrel --- This is an automatically generated e-mail. To reply, visit:

Re: releaseType?

As a starting point for discussion, I’ve set the version on the release/1.0.0-incubating-alpha1 branch to: 1.0.0-incubating-alpha1 Is there a preference to follow the Spring convention as John is suggesting? Are there many / any ASF projects following that convention?. Here’ s what

Re: releaseType?

For clarification, the "RELEASE" version qualifier is only used for the final GA (production-grade release), not any other version. So, by way of example, (using Spring Data GemFire [0]) the release series will progress as

Re: releaseType?

I prefer the Spring model on release numbering/labeling. Also since I'm one of the folks who has to work on both projects, I really want this to be consistent between Apache Geode (incubating) and Spring Data GemFire. -Kirk On Fri, Jan 8, 2016 at 10:58 AM, Swapnil Bawaskar

Re: enabling network partition detection by default

Having a second set of properties is just one more thing that a user has to read but will ultimately not look at or not know about. That's why changing the defaults would be valuable. Either the existing users (who have more experience) need to be made aware of the change in defaults or the new

Re: Review Request 41991: GEODE-245 QueryMonitor cancellation is being ignored by query using CompactRangeIndex

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41991/#review113513 --- Ship it! Ship It! - Jianxia Chen On Jan. 6, 2016, 9:43 p.m.,

Re: releaseType?

+1 On Fri, Jan 8, 2016 at 11:04 AM, Kirk Lund wrote: > I prefer the Spring model on release numbering/labeling. Also since I'm one > of the folks who has to work on both projects, I really want this to be > consistent between Apache Geode (incubating) and Spring Data GemFire.

Re: Review Request 42099: Fix for 52550 issue

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42099/ --- (Updated Jan. 9, 2016, 7:01 a.m.) Review request for geode, Bruce Schuchardt

Review Request 42099: Fix for Garmin issue

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42099/ --- Review request for geode, Bruce Schuchardt and Dan Smith. Bugs: GEODE-774

Re: releaseType?

Note, that in ASF the RCs are NOT published into public Maven repo and are generally not disclosed ouside of the dev. community. Thanks, Roman. On Fri, Jan 8, 2016 at 10:48 AM, John Blum wrote: > For clarification, the "RELEASE" version qualifier is only used for the > final

Re: How are we numbering the first release of Apache Geode?

I think it’s confusing to start with 9.0 when the prior releases were a commercial product, not an open source project. Groovy maintained its versioning pattern when it entered ASF but it has always been OSS and the prior versions are still available. YMMV, Anthony > On Jan 8, 2016, at 3:16

Re: Open pull requests

On Fri, Jan 8, 2016 at 5:38 PM, William Markito wrote: > Well, if we still have some remaining PR's open that are not being closed > properly by the merges, let's ask asf infra to close them, no big deal. Why bother INFRA? Why not ask originators of PRs to close them?

Re: Open pull requests

We had problems in the past with at least 2 PRs that got merged and got stuck there with the need for manual intervention. The original authors were not responsive so INFRA did the clean up. It may not be the case this time so let's try commenting on the PRs asking for them to be closed

Re: updated cwiki page

Looks good to me. Thanks! Sent from my iPhone > On Jan 8, 2016, at 5:29 PM, Karen Miller wrote: > > I've given a general edit to the cwiki page called CacheWriter and > CacheListener Best Practices. > Find this page on the cwiki under Application Development -> Develop,

Re: enabling network partition detection by default

I'm not sure I want to do wholesale defaults revision. Yes this is a release that cannot be done in a rolling fashion, but it is not (yet) a release that requires that pre-existing users to change their settings in general to keep their current configuration. I think it would be simple enough to

Re: Open pull requests

That's probably caused by the fact that many of us are just learning git. -Kirk On Fri, Jan 8, 2016 at 9:34 AM, John Blum wrote: > I guess the only reason I mention it is the Apache Geode commit history is > a mess (inconsistent, in many cases, no correlation to the

Re: enabling network partition detection by default

What’s the level of concern here about members getting kicked out prematurely depending on the newly proposed default settings? For instance, if the default suspect notification is 3 seconds and they are running in AWS or a mildly unpredictable network environment, a member could be kicked

Re: Open pull requests

The problem in this case is that the changes for the PR were committed without "Closes #38" so that PR remains open. I don't have permissions on https://github.com/apache/incubator-geode to close any PRs manually. The only way I know of to close them is via a commit that includes "Closes #38" in

Re: Open pull requests

I guess the only reason I mention it is the Apache Geode commit history is a mess (inconsistent, in many cases, no correlation to the changelog or JIRA tickets, etc)... Running a git log -v --graph also illustrates another problem (a non-linear series of commits cause by not rebasing, which ought

Re: releaseType?

I think we can keep it snapshot until it actually becomes a final release... Ideally it would go - *SNAPSHOT -> BETA, RC, RC2 - Release* - but by keeping it snapshots until the "final" release will probably easy the process, unless ASF requires otherwise. By the way, I'm looking into this -

Re: Review Request 41836: GEODE-719: Add error logs while cache.xml processing

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41836/ --- (Updated Jan. 8, 2016, 5:14 p.m.) Review request for geode and Darrel

Re: Open pull requests

You don't need to push commits to close PRs (at least not in GitHub; not sure how Apace works). On Fri, Jan 8, 2016 at 9:14 AM, Kirk Lund wrote: > Since #36 and #38 were already merged into develop via #42, should I closed > them with two separate empty commits or is there a

Re: Deprecating subregions

I think as Jake stated, there is no "grey" area here. As it is either a feature or it isn't. When a client upgrades the release notes will call it out. --Udo On 1/7/16 7:41 PM, Rajiv Kumar wrote: +1 I have seen subregions being used by many customers especially banking customers. I hope we

Re: Open pull requests

I just clarify, when you push the "patch" associated with the PR (if done properly) it will automatically close the PR. If not done properly, then you can manually close it without a commit. On Fri, Jan 8, 2016 at 9:16 AM, John Blum wrote: > You don't need to push commits to