Re: Default branch for geode-examples

I believe master is still the best default branch for most users. Can we add a PR template for geode-examples reminding developers that examples PRs must be based on develop, not master? Generally the only difference between examples' develop and master is which maven repo it points to (snapsh

Re: Pull Request builder timing out

This PR changes 17 tests. At 50 repeats each, that’s 850 tests. I’m not sure if StressNew does all 850 serially — if it does, they would have to complete in under 10 seconds per test to duck the concourse timeout (currently set a little over 2 hours). Approximately how long do you expect each

Re: [DISCUSS] Replace @TestingOnly with @VisibleForTesting

Sounds good, I would be happy to +1 a PR for this > On Dec 17, 2018, at 12:22 PM, Kirk Lund wrote: > > We have a custom annotation in geode-common called @TestingOnly: > > geode-common/src/main/java/org/apache/geode/annotations/TestingOnly.java > > This annotation was created while pairing wit

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

My feeling is that a 1.8.1 is not the right response. If we can put the missing jars in place manually for 1.8.0 that should be sufficient. -Owen > On Dec 21, 2018, at 9:16 AM, Alexander Murmann wrote: > > I confirmed what we upload to the Nexus staging site again with both 1.7 > and 1.8. I t

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

> Owen, changing what's in a particular version of a library after it has > been shipped to me breaks the contract established by the version number, > regardless of how minor the changes are. > > On Fri, Dec 21, 2018 at 12:04 PM Owen Nichols wrote: > >> My feeling is tha

Re: GfshConsoleModeUnitTest is failing in UnitTest

There is a ticket for this, https://issues.apache.org/jira/browse/GEODE-6370 The problem “seems" to have started with this change: commit 7f10f3a297eeeb473c3f16fff9465df9b404a21c Date: Wed Feb 6 08:33:53 2019 -0800 GEODE-6364: Deploy of invalid jar file does not write file contents to con

Re: Very red CI -> Hold merges, please

Pipeline is back to green now. Thank you to everyone who stepped up to get things back on track. If you had PR checks fail this week, please re-trigger them (by making an empty commit). > On Feb 7, 2019, at 4:20 PM, Alexander Murmann wrote: > > Bruce, would it make sense to for now revert t

Re: Should Geode stats conform to backwards compatibility constraints?

Is it possible for the underlying counter to be maintained as a long, and change the getInt method to return as normal when the value is within MAX_INT, otherwise throw an exception and/or return MAX_INT when the long value would overflow an int? For the MX Bean, should we keep (but deprecate)

Re: Merging GEODE-6424 into release/1.9.0

My vote: Let’s get this into 1.9 On Wed, Feb 20, 2019 at 12:25 PM Jacob Barrett wrote: > Anyone have issue with merging > https://issues.apache.org/jira/browse/GEODE-6424 < > https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0? > > Without it we will have to wait for the next re

Re: Release branch for Apache Geode 1.9.0 has been cut

I would like to see https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-images/jobs/build-google-windows-geode-builder/builds/15 succeed and a run of windows tests on the develop pipeline using this image, if that goes well then +1 for bringing into 1.9 release branch. > O

Re: Release branch for Apache Geode 1.9.0 has been cut

Looks good, I see https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/285 ran successfully using the new image. Please bring this fix into 1.9.0. > On Feb 21, 2019, at 2:21 PM, Owen Nichols wrote: > > I would li

Re: Changes to statistics types

This seems like an entirely reasonable bugfix to make in a minor release. A “release note” mentioning the change should be more than sufficient to alert anyone who may be directly accessing stats. For me, the key information here is "This change does not affect VSD”. For most people, VSD is t

would like to bring GEODE-6447 to 1.9.0 (fix bind exceptions in Windows tests)

This would eliminate a lot of noise from Windows tests, any objection to cherry-picking it to release/1.9.0? This is a test-only change. Thanks, -Owen

Re: 1.9 release date

The release criteria of “based on meeting quality goals” sounds great. What are those quality goals exactly, and can we objectively measure progress against them? It looks like we already have a number of well-defined quality goals in https://cwiki.apache.org/confluence/display/GEODE/Release+pr

Re: 1.9 release date

ver, we've also seen in >>> the >>>> past that we sometimes find new issues by continue work on the code and >>>> some folks starting to use them on their own projects. For that >> reason, I >>>> think it might be wise to give ourselves som

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

gt;>>> Nevertheless looks like develop is more stable than release branch due >>>> to some test fixes that were not cherry-picked into the release branch. >>>> I think its a good idea to re-cut the branch as our current position >>>> to stabili

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

comfortable releasing these new >>>>>>>>> experimental features as they are right now? >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>>> On Tue, Mar 19, 2019 at 2:38 PM Dick Ca

Re: 1.9 release date

The daily trigger was inadvertently lost when the 1.9.0 release branch was re-cut. I’ve just restored it. > On Mar 1, 2019, at 4:33 PM, Owen Nichols wrote: > > Definitely makes sense to have some soak time, as it appears we just reached > “code complete” this morning. > &g

Request wiki edit permission

Hi, my Apache LDAP username is onichols. I would like to request permission to edit https://cwiki.apache.org/confluence/display/GEODE wiki pages.

Request for access to upload Apache Geode artifacts to Docker Hub

To prepare the 1.9.0 RC4 release, the instructions say I need to request dockerhub access. My dockerhub account is: onichols Email: onich...@pivotal.io Thanks!

Re: Propose GEODE-6544 fix for release 1.9.0

Hi Aaron, Kirk and Geode community, FYI, 1.9.0.RC4 has already been tagged and is being prepared for a VOTE email to go out later today. [As usual] if you or anyone else feels that 1.9.0 should not ship without this or other changes, you may cast a “-1” vote once you receive the 1.9.0.RC4 VOTE

[VOTE] Apache Geode 1.9.0 RC4

Hello, Geode dev community, This is the fourth release candidate for Apache Geode, version 1.9.0. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback. The deadline is before 3 PM PST Wed April 24th, 2019. 1.9.0 resolves 296 i

Request for bulk transition permission in Geode Jira

As per Geode release manager instructions, I will need to bulk-transition resolved issues to completed (once we have voted to release a 1.9.0 RC). Please grant me Jira 'bulk-transition’ permissions. Thanks, -Owen

Re: [VOTE] Apache Geode 1.9.0 RC4

e-release-check against the repo. > > -Dan > > On Fri, Apr 19, 2019 at 5:00 PM Owen Nichols <mailto:onich...@pivotal.io>> wrote: > >> Hello, Geode dev community, >> >> >> This is the fourth release candidate for Apache Geode, version 1.9.0. >&g

Re: [VOTE] Apache Geode 1.9.0 RC4

It's past the announced deadline and we have enough votes to close the vote. Voting status == +1: 6 binding votes * Dan Smith (PMC member) * Dave Barnes (PMC member) * Owen Nichols (PMC member) * Ryan McMahon (PMC member) * Dick Cavender (PMC member) * Nabarun Nag (PMC Member) * Ch

[ANNOUNCE] Apache Geode 1.9.0

<https://geode.apache.org/releases/> The release documentation is available at: https://geode.apache.org/docs/guide/19/about_geode.html <https://geode.apache.org/docs/guide/19/about_geode.html> We would like to thank all the contributors that made the release possible. Regards, Owen N

[DISCUSS] reduce PR checks to JDK11 only

Currently every PR commit triggers both JDK8 and JDK11 versions of each test job. I propose that we can eliminate the JDK8 version of each check. In the extremely rare case where a code change breaks on Java 8 but works fine on Java 11, it would still be caught by the main pipeline (just as Wi

[DISCUSS] run Windows tests concurrently with Linux tests in main pipeline

Currently we wait to run the Windows tests for a commit until all the Linux tests have passed. This results in unnecessarily long feedback time to know if a commit passed on Windows. The only benefit of staggering is a small efficiency in resource usage when a breaking commit is merged to deve

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

For a very long time we’ve had Windows tests in the main pipeline (hidden away, not in the default view), but the pipeline proceeds to publish regardless of whether Windows tests fail or even run at all. Now seems like a good time to review whether to: a) treat Windows tests as first-class tests

Re: [DISCUSS] reduce PR checks to JDK11 only

May 15, 2019 at 6:09 PM Owen Nichols wrote: > >> Currently every PR commit triggers both JDK8 and JDK11 versions of each >> test job. I propose that we can eliminate the JDK8 version of each check. >> In the extremely rare case where a code change breaks on Java 8 but w

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

, 2019 at 2:23 PM Bruce Schuchardt > wrote: > >> big +1, as long as artifacts of failed runs can be downloaded >> >> On 5/15/19 6:28 PM, Owen Nichols wrote: >>> For a very long time we’ve had Windows tests in the main pipeline >> (hidden away, not in the default

Re: [DISCUSS] run Windows tests concurrently with Linux tests in main pipeline

view that would result is mitigated by the “JDK 11 only” PR https://github.com/apache/geode/pull/3598 which hides JDK8 tests in the main view to restore sanity. > On May 15, 2019, at 6:18 PM, Owen Nichols wrote: > > Currently we wait to run the Windows tests for a commit until all

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

19, at 3:06 PM, Blake Bender >> wrote: >>>>> >>>>> +1 this needs to happen. I hope that doesn't cause too much pain for >>> the >>>>> dev team, but the native client team has a hard requirement that all >>> our >>>

Re: [DISCUSS] reduce PR checks to JDK11 only

ch if changed the serializable > format of classes. I think if the "golden" checksums were regenerated with > jdk 11 then these tests could be enabled when run on jdk 11. Others on the > dev list may have more of the details. > > On Thu, May 16, 2019 at 5:31 PM Owen Nicho

Re: [DISCUSS] reduce PR checks to JDK11 only

the jdk 8 class files. The >>> byte >>>> codes are different for jdk 11. So by pull requests runs only happening >>> on >>>> jdk 11 we will lose coverage. These tests catch if changed the >>> serializable >>>> format of classes. I th

Re: Changing external methods to no longer throw UnsupportedOperationException

+1 I see no semantic difference between adding a new method vs implementing a stub that previously threw UnsupportedOperationException > On May 23, 2019, at 12:56 PM, Udo Kohlmeyer wrote: > > +1 to implementing this method. > > There is no plausible reason NOT to implement this. > > --Udo >

Re: [DISCUSS] Remove exception.getMessage() error handling

Here’s an example of a message that was logged before Jack’s change: l192.168.99.1: nodename nor servname provided, or not known Here’s what it will look like now with .toString() instead of .getMessage(): java.net.UnknownHostException: l192.168.99.1: nodename nor servname provided, or not know

Re: [DISCUSS] Remove exception.getMessage() error handling

that correct? > On May 28, 2019, at 10:03 AM, Anthony Baker wrote: > > In the example you provided, I don’t agree that adding the exception class > name creates a better user experience. > > Anthony > > >> On May 25, 2019, at 6:39 PM, Owen Nichols wrote: >>

Re: [DISCUSS] Criteria for PMC, committers

I don’t see a compelling reason for Geode to make a distinction between committer and PMC member. If you have the power to merge PRs, you are a steward of the codebase; we need to be able to trust that you have Geode’s best interests at heart and will adhere to our practices. PMC membership c

Re: [DISCUSS] Remove exception.getMessage() error handling

ion rather than an > exception class name. > > Regards > Nabarun Nag > > On Tue, May 28, 2019 at 3:08 PM Owen Nichols wrote: > >> This example came from https://issues.apache.org/jira/browse/GEODE-6796 >> in which the submitter assumed that Geode was deliberately emit

[DISCUSS] require reviews before merging a PR

It seems common for Geode PRs to get merged with only a single green checkmark in GitHub. According to https://www.apache.org/foundation/voting.html we should not be merging PRs with fewer than 3 green checkmarks. Consensus is a fundamental value in doing things The Apache Way. A single +1 is

Re: [DISCUSS] Criteria for PMC, committers

A 6-month waiting period from committer to PMC is tempting because it’s easy to implement, but as you described it yourself, it is arbitrary, which ultimately de-values what it means to be a member of the Geode PMC. The bottom of https://www.apache.org/foundation/voting.html explains why The Ap

Re: [DISCUSS] require reviews before merging a PR

rience is different but I find it hard enough to get even one > person to review my pull requests. I've resorted to merging minor changes > without a review a few times due to lack of response. > > > On 5/30/19 3:51 PM, Owen Nichols wrote: >> It seems common for Geode P

Re: [DISCUSS] Criteria for PMC, committers

ady then > there isn’t a problem. I don’t think we are. I think we have a problem. > > -Jake > > >> On May 30, 2019, at 4:17 PM, Owen Nichols wrote: >> >> A 6-month waiting period from committer to PMC is tempting because it’s easy >> to implement,

Re: [DISCUSS] require reviews before merging a PR

s' time. > > On Thu, May 30, 2019 at 10:12 PM Jacob Barrett > wrote: > > > > > > > > On May 30, 2019, at 4:47 PM, Owen Nichols wrote: > > > > > > Some folks have found it really helpful to have the PR author schedule > a > > wa

Re: [DISCUSS] require reviews before merging a PR

/www.apache.org/foundation/voting.html . "code modification" == > "every PR" is a interpretation that I think would bring the project to a > grinding halt. > > On Fri, May 31, 2019 at 9:01 AM Jacob Barrett wrote: > >> >> >>> On May 31, 20

Re: [DISCUSS] require reviews before merging a PR

cob Barrett wrote: > > >> On May 31, 2019, at 8:52 AM, Owen Nichols wrote: >> >> Apache requires 3 reviews for code changes. Docs and typos likely would not >> fall under that heading. > > Where is this listed as a requirement? The link you sent before offere

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

Personally, I do not force-push to my PRs once any review comments have been accumulated, for the reasons you mention. Not sure if some people just force-push out of habit, or if the requirement for initial commit to be squashed creates some fear. I would go a step further and suggest that ther

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

I’ve almost never seen a PR where this checklist was filled out. Either the PR is created with the original boilerplate intact (or sometimes it’s deleted entirely). I feel like this wall of boilerplate discourages contributors from instead using that space to describe their change and add othe

Re: [DISCUSS] Disable merge for failing pull requests

I’d like to follow up on this discussion from late last year. Six months ago, Kirk wrote: > After we get it more consistently GREEN, I would be willing to change my vote > to +1. While we’re still not perfect, I have noticed that PR checks go green much more consistently now than they did six

Re: Unnecessary uses of final on local variables

I recommend: * Use final if you want to * Don’t -1 someone’s PR because they did or didn’t use final. Personally, there is one case where I like to use final on a local variable: forcing the compiler to tell me if I’ve covered all code paths. Here’s a very simple example: final int x; if (con

Re: [DISCUSS] Adoption of a Coding Standard

I like the idea of a recommended reading list for Geode contributors. My concerns around adopting broad standards and guidelines that can’t be automatically checked & applied are twofold: a) what is the policy regarding existing code? Is every PR going forward expected to bring every file it

[DISCUSS] feedback on new experimental Cluster Management Service

Starting with discussions over a year ago, the Geode community recognized the need for a new API for cluster management and cluster configuration management. Currently this requires a mix of properties, xml files, and gfsh commands. The envisioned “v2” API would expose identical REST and Java

Re: [DISCUSS] Time to cut Geode 1.10.0?

> I was expecting more discussion around this. I have some objections to the > current approach/design. I encourage you to start a [DISCUSS] thread! Also, thank you for the reminder that not everyone has been closely following the recent Cluster Management Service PRs, and since the original

Re: Assigning Jira Issues

Welcome to the Geode community, Alex! We’d love to have your help looking at this ticket. I wasn’t able to find an existing Jira account for “agrisham”. To use Geode JIRA, you first need to sign up for an apache account, then I can

Re: Assigning Jira Issues

You are now assigned :) By the way, this ticket is in an area of code I’m familiar with. Feel free to reach out to me if you have any questions or for code review. > On Jul 29, 2019, at 9:55 AM, Owen Nichols wrote: > > Welcome to the Geode community, Alex! We’d love to have

Re: [DISCUSS] Time to cut Geode 1.10.0?

Our "critical issue” rule has the effect that the bar to commit to develop is “low”, but the bar to cherry-pick to support branch is “very high”. Contributors could plan around this disparity more easily if any of the following were true: - releases were more frequent - planned cut date of relea

Re: [DISCUSS] Time to cut Geode 1.10.0?

code, >> or I want the code to match the documentation. >> The fix in GEODE-7013 changes the code to match the existing documentation, >> so we don't have to change the documentation >> (which would have needed to be cherry-picked into our 1.10 release branch). >

Re: New release branch for Apache Geode 1.10.0

Hi Naba, thank you for bringing your concern. Our current process dictates a time-based schedule to cut release branches. Once cut, the “critical fixes” rule allows critic

Re: New release branch for Apache Geode 1.10.0

ps://issues.apache.org/jira/browse/GEODE-7001> has been marked as 'resolved in' 1.10.0. -Owen > On Aug 2, 2019, at 5:21 PM, Michael Oleske wrote: > > Naba's concern was this PR: https://github.com/apache/geode/pull/3880 which > has been merged to develop > > -

Re: [DISCUSS] Time to cut Geode 1.10.0?

>> Ideally this is kept up to date during development as the dependencies >> change or are added but this often is missed and needs to be reconciled on >> develop before we cut a release branch. >> >> -Dick >> >> >> >> >> >> On Tu

Re: [DISCUSS] Time to cut Geode 1.10.0?

ependency. I would prefer that it is resolved in this >> release and not wait for 3-4 months. >> >> Regards >> Naba >> >> >> >> On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols wrote: >> >>> Hi Kirk, thank you for bringing your concern. >

Re: Another change for 1.10.0 release

Hi Dan, thank you for bringing your concern. Our “critical fixes” rule allows critical fixes to be brought to the release branch by proposal on the dev list [as you have just done]. If there is consensus from the Geode community that this GEODE-7055 fix satisfies the “critical fixes” rule, Dic

Re: Another change for 1.10.0 release

amos wrote: > > +1 > > On Thu, Aug 8, 2019 at 6:41 PM Ryan McMahon wrote: > >> +1 >> >> On Thu, Aug 8, 2019 at 10:40 AM John Blum wrote: >> >>> +1 for Dan's changes. >>> >>> On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

Hi Kirk and Mark, thank you for bringing your concern. Our “critical fixes” rule allows critical fixes to be brought to the release branch by proposal on the dev list, as you have just done. If there is consensus from the Geode community that this NPE fix satisfies the “critical fixes” rule, D

Re: Fix for ClassCastException when using Logback for 1.10.0

There appears to be consensus that this is a critical fix. The following commit has been brought into support/1.10.0 as the critical fix for GEODE-7050 : git cherry-pick -x e5c9c420f462149fd0

Re: SSL Alias Support for JMX Connections

Hi Juan and Sai, thank you for bringing your concern. Geode's release process dictates a time-based schedule to cut release branches. The release/1.10.0 branch was already

Re: SSL Alias Support for JMX Connections

Kirk Lund wrote: > > +1 > > On Fri, Aug 9, 2019 at 9:38 AM Jason Huynh wrote: > >> +1 >> >> On Thu, Aug 8, 2019 at 7:12 PM Owen Nichols wrote: >> >>> Hi Juan and Sai, thank you for bringing your concern. >>> >>> Geode's re

Re: Unit tests are hanging?

Done (increased from 10 minutes to 20 minutes for PR pipeline, and changed from none to 20 minutes for develop pipeline). -Owen > On Aug 10, 2019, at 11:01 AM, Kirk Lund wrote: > > I just saw the Build job exceed timeout during pmdMain so I think we need > to increase its timeout as well. > ht

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

Hi Bruce, thank you for bringing your concern. Geode's release process dictates a time-based schedule to cut release branches. The release/1.10.0 branch was already cut 2

Re: Proposal to Include GEODE-7079 in 1.10.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.10.0 as the critical fix for GEODE-7079 : git cherry-pick -x 6f4bbbd96bcecdb82c

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

I will pair with you on a 1.9.1 release. > On Aug 19, 2019, at 9:23 AM, Kirk Lund wrote: > > I volunteer to pair with a more experienced release manager for 1.9.1. > Anyone willing to mentor me on this? > > On Sun, Aug 18, 2019 at 7:53 AM Anthony Baker wrote: > >> Yep. Get a release manager,

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

urmann > wrote: > >> +1 >> >> it's a regression in 1.10 and a serious problem. >> >> On Mon, Aug 19, 2019 at 7:38 AM Bruce Schuchardt >> wrote: >> >>> It sounds like Udo is okay with this now. Any other concerns? >>>

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

ed there but > there's no way to test it via Concourse. > > On 8/19/19 9:44 AM, Owen Nichols wrote: >> Hi Bruce, unfortunately 8e9b04470264983d0aa1c7900f6e9be2374549d9 does not >> cherry-pick cleanly into release/1.10.0. Can you please open a PR against >> relea

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

sues.apache.org/jira/browse/GEODE-3870>. GEODE-3870 <https://issues.apache.org/jira/browse/GEODE-3870> has been marked as to 'resolved in' 1.10.0. -Owen > On Aug 19, 2019, at 9:44 AM, Owen Nichols wrote: > > Hi Bruce, unfortunately 8e9b04470264983d0aa1c7900f6e9be237

New release branch for Apache Geode 1.9.1

branch. If no concerns are raised, we will start with the voting for the release candidate soon. Regards Owen Nichols & Kirk Lund [1] https://lists.apache.org/thread.html/4a7a6bc24ad7b9eb535fa3f411b4a5fdc2fc33fe5da76d259f0ebfce@%3Cdev.geode.apache.org%3E <https://lists.apach

[VOTE] Apache Geode 1.9.1 RC1

de-examples: ./gradlew -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1055 build runAll Regards Owen Nichols & Kirk Lund

Re: Propose including GEODE-7085 in 1.10

There appears to be consensus that this is a critical fix. The following commits have been brought into support/1.10.0 as the critical fix for GEODE-7085 : git cherry-pick -x f58710116db1cd8c

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

Hi Ryan, thank you for bringing your concern. Geode's release process dictates a time-based schedule to cut release branches. The release/1.10.0 branch was already cut ov

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

Udo, it sounds like you would like to modify the release process to start the stabilization work on develop (rather than cutting the branch as the first step). I would love to hear community opinion on this proposal. For 1.10, in the time we have cherry-picked 11 fixes to release/1.10.0, develo

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

There appears to be consensus that these are critical fixes. The following commits have been brought into release/1.10.0 as the critical fix for GEODE-7088 : git cherry-pick -x 174af1d23fb7e0

Re: [VOTE] Apache Geode 1.9.1 RC1

embers with +1 votes and a majority of +1 votes. The matter of what to do next is referred back to the original DISCUSS thread that proposed 1.9.1. -Owen & Kirk > On Aug 22, 2019, at 6:10 PM, Owen Nichols wrote: > > Hello Geode dev community, > > This is a release candidate f

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this thread to continue the discussion. Is there still a need for a 1.9 patch release (especially given that 1.10.0.RC1 is expected later this week)? If so, perhaps we should back up a step or two and first: 1) come to rough con

Re: [VOTE] Apache Geode 1.9.1 RC1

hanged 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

Re: [VOTE] Apache Geode 1.9.1 RC1

? >>>> >>>> -Dan >>>> >>>> On Wed, Aug 28, 2019 at 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 d

[VOTE] Apache Geode 1.9.1 RC2

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 04 2019. Release notes can be found at: http

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

[VOTE] Apache Geode 1.9.1.RC3

Hello Geode dev community, This is a release candidate for Apache Geode, version 1.9.1.RC3. 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 Thu, September 05 2019. Release notes can be found at: http

Re: [VOTE] Apache Geode 1.9.1.RC3

tar >> file, but it is emply if you try to unzip it. >> >> -Dan >> >> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols wrote: >> >>> Hello Geode dev community, >>> >>> This is a release candidate for Apache Geode, version 1.9.1.RC3. >>

Re: [VOTE] Apache Geode 1.9.1.RC3

l that is fixed. > > Anthony > > >> On Sep 3, 2019, at 2:09 PM, Dan Smith wrote: >> >> It looks like the native source is missing from this RC? There is a tar >> file, but it is emply if you try to unzip it. >> >> -Dan >> >> On Fri, Aug

Re: [VOTE] Apache Geode 1.9.1.RC3

, 2019, at 3:25 PM, Anthony Baker wrote: > > Changing my vote to +1. > > Verified: > > - No binaries in source releases > - Signatures and hashes are correct > - Correct LICENSE and NOTICE files > - Builds from source > > > Anthony > > >>

[ANNOUNCE] Apache Geode 1.9.1

the release possible. Regards, Owen Nichols and Kirk Lund on behalf of the Apache Geode team

Re: [VOTE] Apache Geode 1.10.0.RC1

Hi Anthony, thank you for bringing your concern. If there is consensus from the Geode community that your proposed fix satisfies the “critical fixes” rule, I will be happy to bring it to the release/1.10.0 release branch. Regards Dick & Owen > On Sep 6, 2019, at 2:18 PM, Anthony Baker wrote:

Re: [VOTE] Apache Geode 1.10.0.RC1

to 1.10 > -1 to RC1 until then > > On Fri, Sep 6, 2019, 14:21 Owen Nichols wrote: > >> Hi Anthony, thank you for bringing your concern. >> >> If there is consensus from the Geode community that your proposed fix >> satisfies the “critical fixes” rule, I will be

Re: [VOTE] Apache Geode 1.10.0.RC1

onger viable. We will prepare a 1.10.0.RC2 soon. Regards Dick & Owen > On Sep 9, 2019, at 9:01 AM, Dan Smith wrote: > > +1 to getting the source build fix into 1.10. > > -Dan > > On Fri, Sep 6, 2019 at 5:58 PM Owen Nichols wrote: > >> +1 for catching the corre

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

It looks like this has already passed the vote, but I don’t see an explanation anywhere in this thread for what makes this a "critical fix". As I recall release/1.10.0 was branched at the beginning of August, so it seems appropriate to apply a very high level of scrutiny to any continuing propos

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

> On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: > > Owen: > > The reason is: it's already cherry-picked to 1.9. Can you kindly point me to the specific SHA where this was fixed in 1.9? I am not able to find it... > > Gester > > On Thu, Sep 19, 2019

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

t; backported in future if we did not do it now. > > - How extensively has the fix been tested on develop? > We introduced several dunit and junit tests. > > - How “sensitive” is the area of code it touches? > Not sensitive. > > - What new tests have been added? > New du

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

For a pure-java implementation, might be worth considering https://github.com/eiiches/jackson-jq > On Sep 25, 2019, at 9:40 AM, Dan Smith wrote: > > +1 - sounds good. > > BTW - We've previously found libraries that use JNA tend to be more > flaky/platform dependent than pure java libaries - fo

Re: [VOTE] Apache Geode 1.10.0.RC2

+0 ✅ verified that apache-geode-native-1.10.0-src.tar.gz extracts with a versioned top-level directory ✅ set up a small cluster (2 locators, 3 servers, 1 client, ssl enabled) and ran some simple puts, gets, and CQ. ⚠️ I cannot give “+1" yet because the release notes

  1   2   3   4   5   6   >