Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

+1 for Approach 1 based on the fact that it will have a compile error if you don’t implement it, and it is more object oriented. Thanks, Mark > On Sep 15, 2017, at 10:18 AM, Mark Hanson <mhan...@pivotal.io> wrote: > > So we have two approaches as their has been a veto

Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

My vote is unchanged… +1 for on the object. Thanks, Mark > On Sep 15, 2017, at 10:47 AM, Jacob Barrett wrote: > > On Fri, Sep 15, 2017 at 10:40 AM David Kimura wrote: > >> Actually, it looks like Jake is right. According to documentation it's >>

Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Comments inline…. > On Sep 15, 2017, at 10:25 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > -1 to all, comments below. > > >> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mhan...@pivotal.io> wrote: >> >> So we have two approa

[Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr input); Hi All, So there is a question outstanding about whether or not we want to add const to PdxReaderPtr for fromData calls. It seems reasonable and plausible. Proposal: Change to virtual void fromData(const

[VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

; >> >> So that we can do something like: >> >> std::cout << std::to_wstring(pdxser); >> >> Thanks, >> David >> >> On Thu, Sep 14, 2017 at 11:10 AM, Michael William Dodge <mdo...@pivotal.io >>> >> wrote: >> &

Re: [Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

te. All calls to read the state on PdxReader also result > in a change in that state. > > On Fri, Sep 15, 2017 at 10:40 AM Mark Hanson <mhan...@pivotal.io> wrote: > >> Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr >> input); >> >>

Re: [Discuss] Investigation of C++ object return types

this approach serious > thought even though it provides no performance benefit. > > Thanks, > David > > On Mon, Sep 18, 2017 at 10:47 AM, Mark Hanson <mhan...@pivotal.io> wrote: > >> Hi All, >> >> As we are creating a user API, unless there is a si

Re: [Discuss] Investigation of C++ object return types

really, I expect same badness to happen using shared pointer > method if we dereferenced a moved pointer. > > Thanks, > David > > On Mon, Sep 18, 2017 at 11:19 AM, Mark Hanson <mhan...@pivotal.io> wrote: > >> If you think this is a significant ease of use benefit, why

Re: [Discuss] Investigation of C++ object return types

ere we return objects? Just thinking of mocking, which >> always >>>> wants to mock interfaces. >>>> >>>> On Thu, Sep 14, 2017 at 2:25 PM, Michael William Dodge < >> mdo...@pivotal.io >>>>> >>>> wrote: >>>> &g

Re: [DISCUSS] geode-native c++ exceptions

I think that it would be best to abide by using the std::exception as the base. I think it brings with it all the language support and flexibility. There are a few penalties obviously to using std::exception as a base, but I think they are sufficiently offset by using a standard. As far as the

Re: [Discuss] Investigation of C++ object return types

Hi All, I favor the “pointer" approach that is identified in the code sample. There is greater clarity and less bytes seemingly created and written. We do sacrifice the potential ease of using an object, but in all, I think the way our code is structured. It is not conducive to do a value

[Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Hi All, I wanted to broach the subject of moving away from moving away from CacheableStringPtrs for the toString representation of Serializable. It would seem desirable to move to std::string and std::wstring to use more basic types that would be faster to log and the code would be simpler for

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

Here is a link to my branch in my fork that has the changes on it. https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper Thanks, Mark On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson <mhan...@pivotal.io> wrote: > Hi All, > > In reviewing the PdxWrapper class it,

[Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

Hi All, In reviewing the PdxWrapper class it, it seemed like it would be a good move to make this a template class. This will allow better type checking anytime we use it. An example of what is being planned is to change from MyClass object; PdxWrapper((void *) object,...) to PdxWrapper(object,

[Discuss] Use of -1 as Infinite/All for retry related functions...

Hi All, *Question: how should we deal in a very forward and clean fashion with the implicit ambiguity of -1 or all, or infinite, or forever?* *Background:* We are looking to get some feedback on the subject of infinite/all/forever in the geode/geode-native code. In looking at the code, we

Re: [DISCUSS] Clean build takes 10minutes to complete now

+1 > On Sep 11, 2017, at 11:00 AM, Udo Kohlmeyer wrote: > > Hi there, > > With a recent addition to the build scripts, to test lucene backwards > compatibility, a step was added to download a previous version of GEODE. > > This is causing longer build times now, which is a

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

t; > -Jake > > On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson <mhan...@pivotal.io > <mailto:mhan...@pivotal.io>> wrote: > >> So the basic challenge here is for specific API, do we want to focus on >> providing a >> wait forever approach or just use t

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

To be sure, if we find particular API bad/unclear/misnamed, a change is always easy to justify. On Wed, Sep 6, 2017 at 4:37 PM, Mark Hanson <mhan...@pivotal.io> wrote: > To play devil's advocate, > > I have dealt with -1 for years in network development among other places. > I

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

so support the fluent model in that you could > > do > > > this: > > > ClientCache cache = new ClientCacheFactory().set("propName", > > > "propValue").addPoolLocator("addr", 10678).create(); > > > > > > Also

Re: fix geode-old-versions downloads with a clean build?

There was discussion about taking that out I am very hopeful that it happens. Thanks, Mark On Wed, Sep 6, 2017 at 9:25 AM, Galen O'Sullivan wrote: > Hi all, > > I like to run a `./gradlew clean build` when I'm pulling, reviewing, or > about to push a new build. It

[Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

Problem: To fluent and builder model or not to fluent and builder model In the native client we use the factory model of generating objects, we are wondering if a move to the fluent model and the builder pattern would be better. Background: In designing the various types of allocators

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

of increasing timeout on the retries until we give > up. > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 > > On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mhan...@pivotal.io> wrote: > > > I actually don’t really have a strong op

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

?id=3196> > On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > None of the time spent performing the request is deterministic that’s why > there are timeouts. I don’t follow your rational for claiming it complicated > to code. > >> On A

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

ples in the API? > > On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson <mhan...@pivotal.io> wrote: > > > This basic problem exists with the following cases. > > Interval: to do something at an interval > > Wait: to wait a certain length of time > > Retry: to retry a c

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

es almost three years. If >>>>> each >>>>> retry takes as much as 10ms, we're still looking at "retry for as long >>>>> as >>>>> the earth has existed." 32-bit's is much more attainable, of course, >>>>>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

/n parameter style we should > discuss? > >> > >> -Jake > >> > >> > >> Sent from my iPhone > >> > >>> On Aug 31, 2017, at 10:15 AM, Mark Hanson <mhan...@pivotal.io> wrote: > >>> > >>> As I understand it here, t

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

Barrett <jbarr...@pivotal.io> wrote: > On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mhan...@pivotal.io> wrote: > > > I would have to go looking, but the key concept is that this is a bigger > > problem. > > > > interval such as the time between retries >

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

I can also see why the user doing the retries themselves has value. As a lowest common denominator approach, pulling the API is sound. On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhan...@pivotal.io> wrote: > I think the setRetryAttempts really harks back to the case that Bruce was &

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mhan...@pivotal.io> wrote: > >> I can also see why the user doing the retries themselves has value. As a >> lowest common denominator approach, pulling the API is sound. >> >> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson &l

Re: New client protocol configuration

One thing also to consider if you modifying the config structure, is an evented config structure, so that registrants get callbacks if changes are made that are real-time. Thanks, Mark > On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan wrote: > > I don't care too much

Re: [VOTE] C++ standardize on return values only

Hello All, So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion. As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g. On Tue, Oct

Re: [VOTE] C++ standardize on return values only

ata, if you look at it right… What do you think? Thanks, Mark On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson <mhan...@pivotal.io <mailto:mhan...@pivotal.io>> wrote: Hello All, So in doing some work on this subject, we have come across a case that David and I believed wa

Re: [Discussion] Native - Dropping exceptions from Region::getAll

+1 for dropping the exceptions map. > On Oct 23, 2017, at 10:36 AM, Ernest Burghardt wrote: > > +1 drop exceptions map > > On Mon, Oct 23, 2017 at 10:53 AM, Michael William Dodge > wrote: > >> +1 for dropping the exceptions map for symmetry with the

Re: [Discussion] Geode-Native Removing Stats from Public API

+1 On Thu, Nov 16, 2017 at 12:46 PM, Jacob Barrett wrote: > I want to open a discussion regarding the removal of StatisticsFactory and > related APIs from the public API. I can't see that we would want the Geode > Native client to be a first class statistics/metrics

Access to jira to assign and resolve issues...

Hi All, I would like access to Jira to assign and resolve issues for Geode. I am working on this project now and fixing bugs, so access would be useful. Thanks, Mark

Re: [Discuss] CliStrings

From my product background, maintaining a single file is often preferred for localization as mentioned by Mike, the big question, I would ask is how important is localization? If localization is important, then keeping a single or few file(s) will dramatically ease the localization process. So

Re: [DISCUSS] C++ Header only internal library code

Sounds good to me. +1 Thanks, Mark > On Dec 27, 2017, at 9:17 AM, Jacob Barrett wrote: > > As we move more and more to C++11 the use of templates and header only > implementations balloons. For many of these templates to be useful some > internal utilities must be provided

[DISCUSS] Which assert is the right one to use moving forward?

Hi All, In the course fo fixing some tests, I have found that the existing Geode asserts are deprecated. In wanting to leave the code as clean of deprecations as possible, I have come to the inevitable quandary. Which Assert should we be using? JUnit or Assertj? I am happy with either though

Access to the Staging pipeline in concourse.

Hello, I have been doing development on Geode and so I would like to get access to the staging pipeline in https://concourse.apachegeode-ci.info/teams/staging/login . My GitHub login in mhansonp. Thanks, Mark

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

Hi All, In my humble opinion, I think we should create a single location for timeouts and the timeouts should be the same for similar operations, eg. restarting a locator. Further, I think that if the timeout is exceeded, then it should throw a very clear exception stating what has happened.

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 a

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

[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: Avoiding Unpredictability in Our DUnit Testing Rules

It is frowned upon. VM.getVM(0) is now the accepted way to get VM 0. Thanks, Mark > On Nov 21, 2018, at 10:41 AM, Nabarun Nag wrote: > > Will doing this in the test, > > final Host host = Host.getHost(0); > VM server1 = host.getVM(startingVersion, 0); > > be frowned upon, if I use the

Re: Avoiding Unpredictability in Our DUnit Testing Rules

we can't frown upon > Host.getHost(0).getVM(startingVersion, 0). > > On 11/21/18 4:09 PM, Mark Hanson wrote: >> It is frowned upon. VM.getVM(0) is now the accepted way to get VM 0. >> >> Thanks, >> Mark >> >> >>> On Nov 21, 2018, a

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

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

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

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

0, 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

[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

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: > >> PartitionRegi

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 PartitionedRegionStats

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

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

y. 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: [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

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

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.

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

+1 for log4j changes etc. Mark

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:

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

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 process is still around. Maybe >>>

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

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

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

solutely 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 fully closed and has &g

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.

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

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

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 >

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

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

rs 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 >>> >>> Can we

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

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: [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: 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 >

Re: bug fix needed for release/1.11.0

t; 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? I have 2

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: 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, > >

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: [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: 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: 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

Release candidate target date...

Mark Hanson

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

Re: [VOTE] Apache Geode 1.11.0.RC2

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

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

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

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

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 point is to allow a use t

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 >

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 >

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,

[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: 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: [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.

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

  1   2   3   >