Re: [DISCUSSION] De/un-deprecate IndexType ENUM

2020-01-02 Thread John Blum
I thought I recall that the IndexType [1] was *deprecated* in favor of specific methods on the QueryService

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

2020-01-02 Thread Joris Melchior
Hi Kirk, No, I've tried to figure that out but was unsuccessful in doing so. It would be helpful if someone would be able to shed some light on that. On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund wrote: > Hi Joris, I've read the proposal and reviewed the code some. It's not clear > to me why it was

Re: [DISCUSS] What should we do with @Ignore tests?

2020-01-02 Thread John Blum
+1 to Kirk's comments. Also, regarding (c), using AssumeThat [1] (or, alternatively & IMO preferrably, [2]) might provide some temporary relief. [1] https://junit.org/junit4/javadoc/latest/org/junit/Assume.html [2] https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/Assump

Re: [DISCUSS] What should we do with @Ignore tests?

2020-01-02 Thread Kirk Lund
The Geode code base has 328 tests across 145 files with @Ignore. The vast majority of these were disabled pre-Geode because the previous group's policy was to disable any test that failed in CI, then file a bug system ticket, fix it, and re-enable it. However, the process never followed through bey

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

2020-01-02 Thread Kirk Lund
Hi Joris, I've read the proposal and reviewed the code some. It's not clear to me why it was originally deprecated or what the intended new direction (instead of IndexType) was ever going to be. Do you know more about why it was deprecated or what the devs were going to replace it with? On Thu, Ja

Re: [DISCUSS] Proposal to require linear commit history on develop

2020-01-02 Thread Mark Hanson
This is the approach I am using as well Blake. Thanks, Mark > On Jan 2, 2020, at 7:16 AM, Blake Bender wrote: > > That's not how I approach this sort of a change, and to my mind it feels > sort of like that approach is asking for trouble. When I have a refactor > plus a code change, I do the r

Re: [DISCUSS] Proposal to require linear commit history on develop

2020-01-02 Thread Robert Houghton
@onichols Correction: The 'git-flow' workflow that Geode follows is to merge a release commit to master and to develop. On Thu, Dec 19, 2019 at 4:51 PM Owen Nichols wrote: > Dan, to address some of your concerns: > > This proposal is to block merge commit on develop only. The release > process

Re: Wiki access

2020-01-02 Thread Dan Smith
Done! You should have access now. Thanks, -Dan On Thu, Jan 2, 2020 at 3:56 AM Mario Ivanac wrote: > Hi All, > > Happy New Year! > > Can I have access to edit the Geode Wiki? > My username is "mivanac". > > Thanks, > Mario >

Re: [DISCUSS] Proposal to require linear commit history on develop

2020-01-02 Thread Blake Bender
That's not how I approach this sort of a change, and to my mind it feels sort of like that approach is asking for trouble. When I have a refactor plus a code change, I do the refactor on a branch, submit the PR, then branch off of *that* branch to do the feature work. This forces an ordering of t

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

2020-01-02 Thread Joris Melchior
Apart from Bruce's response (thanks!) it's been very quiet on this item. I'll extend the response time to Jan 10. Details at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477 Thanks, Joris. On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt wrote: > This proposal seems r

Wiki access

2020-01-02 Thread Mario Ivanac
Hi All, Happy New Year! Can I have access to edit the Geode Wiki? My username is "mivanac". Thanks, Mario