[Proposal] Adding Micrometer to Apache Geode

Hello All, I would like to propose that we incorporate Micrometer into Geode to allow us to collect statistics and make them more easily available to external services should someone chose to implement support for that. In some basic testing, it does not appear to have a significant impact on

Re: [Proposal] Adding Micrometer to Apache Geode

ard > stats definition and collection API in 2.0. > >> On Jan 15, 2019, at 9:37 AM, Mark Hanson wrote: >> >> Hello All, >> >> I would like to propose that we incorporate Micrometer into Geode to allow >> us to collect statistics and make them more easily avai

Re: [Proposal] Adding Micrometer to Apache Geode

his proposal as long as it includes the deprecation of all >> the current stats APIs and VSD such that Micrometer is the only go forward >> stats definition and collection API in 2.0. >> >>> On Jan 15, 2019, at 9:37 AM, Mark Hanson wrote: >>> >>>

Re: Remove mavenLocal from Geode gradle files

Hi Patrick, If our build should not use a local .m2 cache, then we should remove mavenLocal from the build to avoid these possible friction points. I, for one, like the idea of reduce opportunity for problems in the build. If there is a meaningful benefit to having a mavenLocal, then we should

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

+1 for Jake’s approach. Jake’s approach seems to address the only concern that I know of which is backward compatibility. Thanks, Mark > On Jun 10, 2019, at 11:20 AM, Robert Houghton wrote: > > +1 to @Udo Kohlmeyer comment. If the memory has > been used, might as well allow us to query the

Proposal: For PR reviews and change requests can we have a 7 day turn around on re-reviews?

Hi All, TL;DR Can we have a norm( preferred, but not required ) of providing feedback within seven days of the last checkin to a PR? Long version I have just spent a bit of time reviewing PRs that have been open for a while and sent some emails to reviewers of the ones that are open the longe

Re: Proposal: For PR reviews and change requests can we have a 7 day turn around on re-reviews?

ributors we could assign a committer who will make sure the PR gets >> reviewed and merged in a timely fashion. >> >> -Dan >> >> On Tue, Jul 9, 2019 at 10:34 AM Mark Hanson wrote: >> >>> Hi All, >>> >>> TL;DR >>> >>&

[Proposal] Refactor the Cache and Region perf stats structure.

Hi All, As many of you may know our structure for our perf stats is not great. I would like to propose we refactor the code to have the following inheritance model, which Kirk and I came up with. It is my belief that fixing this will allow future features to be implemented in a much less painf

Re: [Proposal] Refactor the Cache and Region perf stats structure.

Jul 10, 2019 at 4:49 PM Mark Hanson <mailto:mhan...@pivotal.io>> wrote: > Hi All, > > As many of you may know our structure for our perf stats is not great. I > would like to propose we refactor the code to have the following inheritance > model, which Kirk and I came up w

Re: [Proposal] Refactor the Cache and Region perf stats structure.

Correct. > On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote: > > Why would a PartitionedRegionStatsImpl contain more than one RegionStats? > Are these representing the local buckets? > > On Wed, Jul 10, 2019 at 4:57 PM Mark Hanson wrote: > >> PartitionRegionS

Re: [Proposal] Refactor the Cache and Region perf stats structure.

er bucket. Are you saying > you’re making that a thing now? > >> On Jul 11, 2019, at 9:24 AM, Mark Hanson wrote: >> >> Correct. >> >>> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote: >>> >>> Why would a PartitionedRegionStatsImpl

Re: [Proposal] Refactor the Cache and Region perf stats structure.

If this discussion is really about per-bucket stats then let’s > focus the subject on that and not really worry about any internal refactoring > that must happen to make it work. > >> On Jul 11, 2019, at 9:29 AM, Mark Hanson wrote: >> >> It depends to be honest. T

Re: [Proposal] Refactor the Cache and Region perf stats structure.

t;> >>> On Jul 11, 2019, at 9:26 AM, Jacob Barrett wrote: >>> >>> There isn’t currently a partition stat instance per bucket. Are you >> saying you’re making that a thing now? >>> >>>> On Jul 11, 2019, at 9:24 AM, Mark Hanson wrote: >

Re: [Proposal] Refactor the Cache and Region perf stats structure.

ames (like CachePerfStats -> CacheStats) keep > in mind that you should use the same type name when calling "createType" > (in this case "CachePerfStats") for backwards compatibility. > > On Thu, Jul 11, 2019 at 9:45 AM Mark Hanson wrote: > >> See my co

Re: [Proposal] Refactor the Cache and Region perf stats structure.

CachePerfStats -> CacheStats) keep > in mind that you should use the same type name when calling "createType" > (in this case "CachePerfStats") for backwards compatibility. > > On Thu, Jul 11, 2019 at 9:45 AM Mark Hanson wrote: > >> See my comments inline.

Re: [DISCUSS] RFC 0: Lightweight RFC Process

Thanks for taking the initiative Dan! > On Jul 12, 2019, at 12:57 PM, Dan Smith wrote: > > Following up on this, I took a stab at organizing our old proposals into > the buckets on the wiki. We now have: > > Under Discussion - Draft and In Discussion proposals > In Development - proposals under

Re: Need reviewers for #3762: prevent creation of unnecessary PartitionedRegion callback events

Hi Kirk, I pinged Darrel and Jason about it as they reviewed part 1. Thanks, Mark > On Jul 17, 2019, at 1:41 PM, Kirk Lund wrote: > > We need reviewers for PR #3762 -- no one has reviewed it yet: > https://github.com/apache/geode/pull/3762 > > Looks like it involves optimizing PartitionedRegi

Volunteers for PR Review?

Hi All, PR GEODE-3632 throw NotAuthorizedException for getAll https://github.com/apache/geode/pull/3765 This PR currently has no reviewers. Could we get a few people to review it? Thanks, Mark

Reviewers for PR

Hi All, Here is another PR that could use reviewers. GEODE-6748: First part of solution #3854 https://github.com/apache/geode/pull/3854 Thanks, Mark

Re: geode-native ipv6

The latest ACE framework seems to have support, but I don’t know how far off latest we are. I don’t think we test anything in an IPv6 context, so I would say no that we don’t officially support it in the client. Given some time, I could do some testing.. Thanks, Mark > On Aug 8, 2019, at 7:35

Re: Fix for ClassCastException when using Logback for 1.10.0

+1 I think it is valuable to make life easier for Spring Boot users. Thanks, Mark > On Aug 8, 2019, at 11:24 AM, Kirk Lund wrote: > > This is the last logging related fix that I'd like to propose adding to > 1.10.0 > release branch. > > Spring Boot adds Logback and log4j-to-slf4j to the clas

Re: geode-native ipv6

I just tried to connect to Geode with the native client and it did not go well. It exceptioned with an illegal argument error. That said, it “seems" like it might not be complicated to make it IPv6 compliant. Thanks, Mark > On Aug 8, 2019, at 9:56 AM, Mark Hanson wrote: > >

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

+1 to include the fix > On Aug 14, 2019, at 9:06 AM, Kirk Lund wrote: > > +1 to include this fix in 1.10.0 > > FYI: The race condition for this code path to throw NPE (which is > catastrophic and requires restarting the server) was introduced by commit > 279fa0 on July 31 for GEODE-7001. > > O

Re: Odg: Need PR reviews

Hi Jake and Blake, Could you take a look at this? I will test it as well. Thanks, Mark > On Aug 27, 2019, at 9:15 AM, Mario Ivanac wrote: > > Hi, > > just to remind you. > > Thanks. > > Šalje: Mario Ivanac > Poslano: 26. kolovoza 2019. 11:37 > Prima: dev@geo

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

+1 for log4j changes etc. Mark

Re: [VOTE] Apache Geode 1.9.1 RC2

+1 > On Aug 29, 2019, at 5:11 PM, Ryan McMahon wrote: > > +1 > > On Thu, Aug 29, 2019 at 5:11 PM Kirk Lund wrote: > >> +1 >> >> On Thu, Aug 29, 2019 at 5:02 PM Owen Nichols wrote: >> >>> Hello Geode dev community, >>> >>> This is a release candidate for Apache Geode, version 1.9.1.RC2. >>

[Proposal] Make gfsh "stop server" command synchronous

Hello All, I would like to propose that we make the gfsh “stop server” command synchronous. It is causing some issues with some tests as the rest of the calls are blocking. Stop on the other hand immediately returns by comparison. This causes issues as shown in GEODE-7017 specifically. GEODE:70

Re: [Proposal] Make gfsh "stop server" command synchronous

way that the >> server has stopped before returning. >> >> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson wrote: >> >>> Hello All, >>> >>> I would like to propose that we make the gfsh “stop server” command >>> synchronous. It

Re: [Proposal] Make gfsh "stop server" command synchronous

; blocking absolutely maybe less desirable when using *Gfsh* interactively. >>> There are, after all, many non-cluster based commands. >>> >>> @Mark - I see. I have generally found in my own testing purposes, >>> especially automated, that a cache instance is not ful

Re: [Proposal] Make gfsh "stop server" command synchronous

Sep 11, 2019 at 8:17 AM Bruce Schuchardt >> wrote: >> >>> Blocking or non-blocking, I don't have a strong opinion. What I'd >>> really like to have gfsh ensure, though, is that no-one is able to start >>> a new instance of a server while the old proc

Re: Question about excluding serialized classes

They would be the specific functions, but this doesn’t get us around they other problem. I think this approach is not going to work and we are about to start looking into other ways. Thanks, Mark > On Sep 11, 2019, at 12:14 PM, Anthony Baker wrote: > > I think the Decorator approach you outli

Re: [Proposal] Make gfsh "stop server" command synchronous

stopped. > > How will this work if stop server --member is invoked some a different > machine than the member that is being stopped? > > -Dan > > On Wed, Sep 11, 2019 at 10:28 AM Mark Hanson wrote: > >> The idea I am working with at the moment that Kirk pointed m

Re: Please review PR #4024

Hi All, This has been merged. It got three reviews already so we merged it. Thanks, Mark > On Sep 18, 2019, at 4:15 PM, Kirk Lund wrote: > > Please review PR #4024 > https://github.com/apache/geode/pull/4024 > > The purpose of this PR is to reduce flaky failures involving ServerLauncher > te

[VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

Hi All, Since we need a release manager for 1.11 and no one has volunteered, yet. I thought I would volunteer. Thanks, Mark

[Proposal] Cut 1.11.0 branch on November 4th, 2019.

Hi All, Looks like I won the contest to be release manager by default, so let's get started…. I think we should cut the branch on November 4th, 2019. Assuming that is agreed to, I would pick the most stable build during that day. Please get back to me if you have any concerns. Thanks, Mark

The 1.11.0 branch we be cut on November 4th, 2019.

Please ensure that your changes are in November 3rd, 2019 at the latest. I will pick the SHA of the first successful build on November 4th, 2019. If you realize your change will not make the cut and think it should, please let me know. Thanks, Mark Hanson

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

-1 for "Break glass" approach. Needing a break glass approach is a sign. I wonder how hard that would be to make exist. I think our break glass approach is that we have someone with the power disable the restrictions in Github for the window that we must and then we put it back. Thanks, Mark >

Re: upgrading concourse to 5.7.0

Hi Sean, Should I be concerned? I have a bunch of queued up jobs going to test distributed unit tests. Thanks, Mark > On Nov 1, 2019, at 10:06 AM, Sean Goller wrote: > > After testing, we're going to upgrade the concourse infrastructure to 5.7.0 > this morning. We do not anticipate any issue

1.11.0 Release branch has been cut

Hello Geode Dev Community, We have created a new release branch for Apache Geode 1.1100 - “release/1.11.0" Please do review and raise any concern with the release branch. If no concerns are raised, we will start with the voting for the release candidate soon. Regards Mark Hanson

Re: 1.11.0 Release branch has been cut

Argh... Corrected release version below… > On Nov 4, 2019, at 4:47 PM, Mark Hanson wrote: > > Hello Geode Dev Community, > > We have created a new release branch for Apache Geode 1.11.0 - > “release/1.11.0" > > Please do review and raise any concern with the rel

Re: Review for #4204

I took care of it. Best regards, Mark > On Oct 28, 2019, at 8:05 AM, Alberto Gomez wrote: > > Hi, > > Could I ask for a review on https://github.com/apache/geode/pull/4204? > > This PR is about GEODE-7157: > (https://jira.apache.org/jira/browse/GEODE-7157). > > Thanks, > > /Alberto G. > >

Re: Review for #4204

Hi Alberto, Rebasing and merging your fix broke the build. I am going to revert it. Once you resolve the issues. we can remerge it. Thanks, Mark > On Nov 5, 2019, at 9:06 AM, Alberto Gomez wrote: > > Hi, > > Any volunteer to merge this PR that has already been approved? > > Thanks, > > /A

Re: [REQUEST] Squash merge please

Yup. I am a little annoyed at myself about that.. Thanks for the reminder though. Mark > On Nov 5, 2019, at 11:48 AM, Owen Nichols wrote: > > +1 > > When merging a PR from GitHub, if the green button does not already say > “Squash and merge”, click the little triangle and select “Squash and

Re: bug fix needed for release/1.11.0

Any other votes? I have 2 people in favor. Voting will close at noon. Thanks, Mark > On Nov 6, 2019, at 8:00 AM, Bruce Schuchardt wrote: > > The fix for this problem is in the CI pipeline today: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Build/builds

Re: Odg: bug fix needed for release/1.11.0

Thanks Mario. Your vote reminded me not all voters are in the PST time zone.. Pardon my thoughtlessness.. Voting closes at 12pm PST > On Nov 6, 2019, at 9:33 AM, Mario Ivanac wrote: > > +1 for bringing this fix to release/1.11.0 > ____ > Šal

Re: bug fix needed for release/1.11.0

gt;> confirm that it works through the main pipeline, but I feel confident that >> it will pass the benchmark job. >> >> Thanks, >> Helena Bales (they/them) >> >> On Wed, Nov 6, 2019 at 9:28 AM Mark Hanson wrote: >> >>> Any other votes

Re: Adding GEODE-7412 to 1.11 release

Hi, Can someone give me a known good sha? I will add it in. Thanks, Mark > On Nov 8, 2019, at 2:20 PM, Jens Deppe wrote: > > Hmm, I thought this was implicitly fixed by various build refactorings that > went into 1.11.0. I see that we're creating local maven artifacts for > geode-pulse-1.11.0

Release candidate target date...

Mark Hanson

Re: Release candidate target date...

019 at 3:47 PM Owen Nichols wrote: >>> >>> +1 for cutting RC1 within two weeks of creating the release branch :) >>> >>>> On Nov 12, 2019, at 3:00 PM, Mark Hanson wrote: >>>> >>>> Hello Geode Dev Community, >>>>

Re: Propose adding GEODE-7400 fix to 1.11 release

FYI, this has been added to the release/1.11.0 branch. Thanks, Mark > On Nov 11, 2019, at 9:42 AM, Jason Huynh wrote: > > +1 > > On Mon, Nov 11, 2019 at 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 f

Re: Adding GEODE-7412 to 1.11 release

Thanks Udo. > On Nov 13, 2019, at 10:32 AM, Udo Kohlmeyer wrote: > > @Mark, > > According to investigation that has been done, GEODE-7412 is a non-issue.. > Fixed by another ticket, that is already part of /1.11/ and /develop/ > > --Udo > > On 11/8/19 3:3

Re: Release candidate target date...

Hello Geode Dev Community, As I will be doing a building a release candidate in about 5 hours. I am not aware of any serious issues at this moment. If you have any last minute checkins for 1.11.0, now is the time. Thanks, Mark > On Nov 12, 2019, at 3:00 PM, Mark Hanson wrote: > &

Access to upload Apache Geode to Docker Hub.

Hi, I would like to have access to upload to Docker Hub, so I can release Apache Geode to Docker Hub. My DockerHub ID is mhansonp. Thanks, Mark

[VOTE] Apache Geode 1.11.0.RC2

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.11.0.RC2. 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: 3PM PST Mon, November 25 2019.

Access to edit the Geode Wiki

Hi All, Can I have access to edit the Geode Wiki to add release notes? My confluence ID is "mhanson". Thanks, Mark

Re: [VOTE] Apache Geode 1.11.0.RC2

this commit: >>> >> https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c >>> . >>> >>> Thanks, >>> >>> Blake >>> >>> >>> On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson wrote: >>>

Re: Cache.close is not synchronous?

+1 to fix. > On Nov 25, 2019, at 2:02 PM, John Blum wrote: > > +1 ^ 64! > > I found this out the hard way some time ago and is why STDG exists in the > first place (i.e. usability issues, particularly with testing). > > On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote: > >> I found a test tha

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

seUrl=https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3 -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1063 build runAll Regards Mark Hanson

Re: Request for addition to 1.11 RC: GEODE-7454: Docs for Cluster Management Service

Done. > On Dec 3, 2019, at 9:24 AM, Dave Barnes wrote: > > Docs for a feature that's already implemented - no code changes. > Can be cherry-picked from the develop branch as-is with no modifications. > https://github.com/apache/geode/commit/e48f34048c574440ed7e0640f42e9c82d789becb

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 we

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. > > T

Re: Request GEODE-7510/GEODE-7538 be cherry-picked into release 1.11

Can I get the SHA of the commit? Thanks, Mark > On Dec 11, 2019, at 11:02 AM, Jason Huynh wrote: > > Hello, > > GEODE-7538 was highlighted as blocking the 1.11 release. This has now been > addressed and propose that this gets merged over to release 1.11. > > This issue solves a few things, m

[DISCUSS] Adding a couple user APIs dealing with RegionFactory.

Hi All, There was a suggestion that since I am making a couple user visible API changes that I might want to ask the dev list. Basically I was migrating code from AttributesFactory to RegionFactory and hit a few snags along the way. Please see https://github.com/apache/geode/pull/4409

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

createRegionFactory(RegionFactory regionFactory) Thanks, Mark > On Dec 11, 2019, at 3:25 PM, Dan Smith wrote: > > I see a lot of PR comments on those PRs. What is the new API you added? > > -Dan > > On Wed, Dec 11, 2019 at 2:57 PM Mark Hanson wrote: > >&

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

In discussion with Dan, I made a few realizations, so I have new API coming. Basically dropping the use of InternalCache below. Please hold off on reviewing. Thanks, Mark > On Dec 11, 2019, at 3:34 PM, Mark Hanson wrote: > > > In Cache.java > > + RegionFactory c

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

anges will help the user? > > Thanks, > Anthony > > >> On Dec 11, 2019, at 2:57 PM, Mark Hanson wrote: >> >> Hi All, >> >> There was a suggestion that since I am making a couple user visible API >> changes that I might want to ask the dev lis

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

Yup, fixing that. > On Dec 11, 2019, at 3:38 PM, Darrel Schneider wrote: > > Don't expose "InternalCache" on RegionFactory. You probably want it to be > "Cache". > > On Wed, Dec 11, 2019 at 3:35 PM Mark Hanson wrote: > >> >>

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 > &g

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

e'd be adding to the product should be > done through the Management API's for Regions, rather than exposing new > public API's that in reality should not be made "public". > > --Udo > > On 12/11/19 3:53 PM, Mark Hanson wrote: >> Basically the poi

Re: [REQUEST] Squash merge please

I would strongly prefer smaller as small a commit as possible. And as large as necessary. I am less partial when it comes to PRs sizes. Sometimes depending on what is done in a PR, I don’t think it makes sense to issue a blanket statement that all PRs are one commit. I think there is a strong re

[VOTE] Adding a couple user APIs dealing with RegionFactory.

2019 at 9:56 AM Dan Smith wrote: >> >>> +1 to adding a way to copy the RegionAttributes. >>> >>> BTW, I really wish this RegionFactory was an interface. I don't know if >>> adding a copy constructor makes it harder to migrate to an interface late

Re: [VOTE] Adding a couple user APIs dealing with RegionFactory.

copy constructor 0 don’t care -1 stop migrating from AttributesFactory to RegionFactory and wait for Management V2 API. > On Dec 16, 2019, at 11:08 AM, Mark Hanson wrote: > > Actually, I would say that it would not be necessary to have a copy > constructor if it were not for

Re: Propose bringing GEODE-7537 to release/1.11.0

Yes, I agree, but I am waiting on a fix. Eric is supposed to let me know when he feels its good to go. Thanks, Mark > On Dec 16, 2019, at 2:32 PM, Owen Nichols wrote: > > Sorry, the correct ticket is GEODE-7537 > . This was on the short > li

Re: [VOTE] Adding a couple user APIs dealing with RegionFactory.

or the future? > >> On Dec 16, 2019, at 12:13 PM, Mark Hanson wrote: >> >> It has been said I have a negative vote which is counter intuitive. >> >> VOTE SUBJECT: >> >> Should we continue migrating from AttributesFactory usage to RegionFactory >>

[DISCUSS] Does anyone know of any other issues for 1.11.0?

Hi All, I believe at this point, that all outstanding issues have been included in 1.11.0. I would like to do an RC build unless someone advises me otherwise, by 3pm PST. Everyone will still have a few days to try the release candidate, as usual. Thanks, Mark

Re: Proposal to including GEODE-7593 in release/1.11.0

I have added the SHA to the branch. Thanks, Mark > On Dec 19, 2019, at 12:25 PM, Ivan Godwin wrote: > > +1 > > On Thu, Dec 19, 2019 at 11:43 AM Dick Cavender wrote: > >> +1 >> >> On Thu, Dec 19, 2019 at 11:27 AM Udo Kohlmeyer wrote: >> >>> +1 >>> >>> On 12/19/19 10:05 AM, Owen Nichols wr

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

+1 > On Dec 19, 2019, at 4:27 PM, Jinmei Liao wrote: > > +1 > > On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote: > >> I’d like to advance this topic from an informal request/discussion to a >> discussion of a concrete proposal. >> >> To recap, it sounds like there is general agreement that

[VOTE] Apache Geode 1.11.0.RC4

geode-examples: ./gradlew -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC4 -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1064 build runAll Regards Mark Hanson

Re: [VOTE] Apache Geode 1.11.0.RC4

Given it is the holidays, perhaps more time is in order. I am bumping the voting deadline to Friday, December 27th, 2019. Thanks, Mark > On Dec 20, 2019, at 2:46 PM, Mark Hanson wrote: > > Subject: [VOTE] Apache Geode 1.11.0.RC4 > Hello Geode Dev Community, > > This is a

Re: [VOTE] Apache Geode 1.11.0.RC4

Hi All, It seems that we have the 3 PMC member votes needed plus extra votes, so I will begin the release process for Apache Geode 1.11.0.RC4, once cwiki.apache.org comes back online. Final tallies appear to be. 5 +1 (Yes, release it.) 1 -0 (Releasing is OK, but…

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

This change to disable all but squash-merge would be really easy to revert. How about we try it for a while and see? If people decide it is really limiting them, we can change it back. Let’s do it for 1 month and see how it goes. Does that sound reasonable? Thanks, Mark > On Dec 30, 2019, at 5

[ANNOUNCE] Apache Geode 1.11.0

website:http://geode.apache.org/releases/ The release documentation is available at:http://geode.apache.org/docs/guide/111/about_geode.html We would like to thank all the contributors that made the release possible. Regards, Mark Hanson on behalf of the Apache Geode team

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

Hi All, As part of what I am doing to fix flaky tests, I periodically come across tests that are @Ignore’d. I am curious what we would like to do with them generally speaking. We could fix them, which would seem obvious, but we are struggling to fix flaky tests as it is. We could delete them,

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

gt;>> at random. >>>>> - I'd rather be deliberate about what tests we introduce than >>> wholesale >>>>> bring back a set of tests, since any of these re-introduced tests >>> has a >>>>> potential to be flaky.

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

gt; merge >>>>>> options >>>>>>>>> from GitHub, leaving only Squash and Merge. PR #4513 >>>>>>>>> <https://github.com/apache/geode/pull/4513> serves as an >> exhibit >>>> of >>>>>>>

[DISCUSS] Someone to update 3rd-party libraries used by GEODE

code. We would need to get this done within the next week or two, so that we have time to shake out issues before the next release. Regards, Mark Hanson on behalf of the Apache Geode team

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

; wrote: >> >>> Here are a few things that are true for me or I believe are true in >>> general: >>> >>> - Our test suite is more flaky than we'd like it to be >>> - I don't believe that adding more Unit tests that follow existing >&g

Release Manager for 1.12 (February 3rd)

Hello All, It is that time again. It is time to cut a new release branch for 1.12 on February 3rd. We need a volunteer! No experience required. Committer status would be helpful, but not required. In the mean time, we should focus on ensuring the CI is stable and start planning to cut the bra

Re: [DISCUSS] include geode-benchmarks in 1.12 release

Just my two cents. I think that we should probably strip CI into a separate repo. The key indicator is that if something were wrong in the CI yaml, would I hold a release for that? I think no. So that suggests to me it is a separate thing. Same goes for benchmarks. If we were failing a benchmar

A Release Hero/Manager is needed for 1.12 (February 3rd)

Just a reminder, still looking for that release manager… Please don’t all volunteer at once! Glory and street cred await the intrepid release manager volunteer. Hello All, It is that time again. It is time to cut a new release branch for 1.12 on February 3rd. We need a volunteer! No experie

Release Manager for 1.12.0: We have a volunteer!

Hi All, Ernest Burghardt (@echobravopapa on github) has volunteered to take on the Release Manager responsibilities for 1.12.0. Thank you Ernie! Best regards, Mark

Question regarding a ConnectionPoolDUnitTest failure

Hi All, I could use a little help understanding the expected behavior for a test case. We are registering for events and we are getting destroys for destroys, creates for creates etc. However, in the case of a recreate, it seems like we are getting an entry event of LOCAL_LOAD_CREATE and some

Re: [Vote] Include GEODE-7752 into 1.12

Hi Ernie, Thanks for the heads up. This is breaking DistributedTestOpenJDK and Udo confirmed the are of concern and is going to revert this. Thanks, Mark > On Feb 5, 2020, at 4:14 PM, Ernest Burghardt wrote: > > Udo, > the PR has some failing tests that are in the "non-mandatory" category fo

[Question] I had a PR that didn't run a StressNewTestOpenJDK11(really), but passed?

Hi, Why is that? It gave the error message in the log of " 17:26:13 66 changed tests 17:26:13 66 is too many changed tests to stress test. Allowing this job to pass without stress testing.” I didn’t touch 66 files. I touched 5 classes. It maybe that there are 66 tests therein, but if that is t

[PROPOSAL] StressNewTest in Pull Request Pipeline to be made optional.

Hi All, Proposal: Force StressNewTest to fail a change with 25 or more files rather than pass it without running it. Currently, the StressNewTest job in the pipeline will just pass a job that has more than 25 files changed. It will be marked as green with no work done. There are reasons, relat

Re: [PROPOSAL] StressNewTest in Pull Request Pipeline to be made optional.

run all tests 25x instead of 50x). >> >> While StressNew is intended to catch new flaky tests, it can also catch >> poorly-designed tests that fail just by running twice in the same VM. This >> may be a sign that the test does not clean up properly and could be >> pol

Re: [PROPOSAL] StressNewTest in Pull Request Pipeline to be made optional.

gt;>>> with 50 repeats if fewer than 25 files changed, otherwise compute 1250 / >>>> <#-files-changed> and do only that many repeats (e.g. if 50 files >> changed, >>>> run all tests 25x instead of 50x). >>>> >>>> While StressNe

Re: PR Titles

If I may add one caveat. If a pull request is in a ready to review state … . If it is prefaced with Do Not Review: then . Thanks, Mark > On Mar 2, 2020, at 9:30 AM, Alexander Murmann wrote: > >> >> Don't we have a published checklist or guideline or something for this >> already? Including s

Re: PR Titles

; is buried at the bottom and is > an important signal being lost in the noise... > > On Mon, Mar 2, 2020 at 10:12 AM Jacob Barrett wrote: > >> >> >>> On Mar 2, 2020, at 10:10 AM, Mark Hanson wrote: >>> >>> If I may add one caveat. If a pull re

Re: Help needed to get my PR to pass the stressNewTest

Hi Eric, When you have a moment, ping me. I can help. I think… Thanks, Mark > On Mar 4, 2020, at 1:27 PM, Eric Shu wrote: > > My PR (https://github.com/apache/geode/pull/4709) continue to fail in > stressNewTest. I have been retrigger the test and all failed with same > issue. I need help to

  1   2   3   >