Re: [DISCUSS] etiquette around breaking the pipeline

+1 to quick reverts. echoing @Donal its best if the committer of the offending commit does the revert On Thu, Apr 30, 2020 at 1:28 AM Ju@N wrote: > I'm in favour of quick reverts as well. > Even though a failure might seem easy to fix at a first glance, experience > has proven otherwise in

[ANNOUNCE] Apache Geode 1.12.0

The Apache Geode community is pleased to announce the availability of Apache Geode 1.12.0. Apache Geode is a data management platform that provides a database-like consistency model, reliable transaction processing and a shared-nothing architecture to maintain very low latency performance with

Re: [VOTE] Apache Geode 1.12.0.RC4

> > 1) Let's be consistent with names of source distribution and > > extensions. > > > > 2) NOTICE file copyright date needs to be updated for -native, > > > > -benchmark, -examples. > > > > 3) Some of the version numbers in LICENSE need to update

[VOTE] Apache Geode 1.12.0.RC4

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.12.0.RC4. 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, March 30, 2020.

[CANCEL] Geode 1.12.0.RC1,2,3

Hi Geode, (Happy Friday, btw) We are cancelling the first 3 RCs to fix some small non-code issues. Best, EB

[VOTE] Apache Geode 1.12.0.RC3

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.12.0.RC3. 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: * Same as before *

[VOTE] Apache Geode 1.12.0.RC2

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.12.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: *Remains same as RC1 as

Re: [VOTE] Apache Geode 1.12.0.RC1

ated with it. It also looks like it just contains a Dockerfile - > is > >> this actually an artifact we want to distribute? > >> > >> -Dan > >> > >> On Wed, Mar 25, 2020 at 2:12 PM Ernest Burghardt > > >> wrote: > >> > >>&

[VOTE] Apache Geode 1.12.0.RC1

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.12.0.RC1. 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, March 30 2020.

Re: [PROPOSAL]: Include GEODE-7832, GEODE-7853 & GEODE-7863 in Geode 1.12.0

There appears to be consensus that these are critical fixes. The following commit has been brought into release/1.12 as the critical fix for GEODE-7832: git cherry-pick -x 2a3e09f2da4793d08d1124b5d5e656285295937d GEODE-7832 has been marked as 'resolved in' 1.12. The following commit has been

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7763: git cherry-pick -x b4c3e9413f0008635b0a0c9116c96147d1e4ceec GEODE-7763 has been marked as 'resolved in' 1.12. Regards EB On Wed, Mar 18, 2020

Re: Next release

Hi Mario, There is still some work to be done to ensure performance is on par with previous releases... here are a few tickets related to the efforts https://issues.apache.org/jira/browse/GEODE-7763 https://issues.apache.org/jira/browse/GEODE-7832 https://issues.apache.org/jira/browse/GEODE-7853

Re: PR Titles

I agree with Jake and do appreciate everyone using the "DRAFT" feature, one downfall of that is this is not visible unless on Github; i.e. if you see an email for a PR you won't know its in "DRAFT" mode until you go look at it... a related part of this, to me, seems to be that the PR checklist is

Re: [PROPOSAL] include GEODE-7829 in 1.12

, 2020 at 1:20 PM Donal Evans wrote: > +1 > > On Fri, Feb 28, 2020 at 1:15 PM Ernest Burghardt > wrote: > > > yes, it was just a transposition/typo when the defaults were > > refactored/moved > > > > On Fri, Feb 28, 2020 at 1:14 PM Owen Nichols > wrote:

Re: [PROPOSAL] include GEODE-7829 in 1.12

o restore? > > > On Feb 28, 2020, at 1:06 PM, Ernest Burghardt > wrote: > > > > bumping this out to DevList as something went wrong in the mail system... > > > > On 2020/02/28 19:27:42, Bruce Schuchardt > wrote: > >> During a refactor the default ack-wait-thr

[PROPOSAL] include GEODE-7829 in 1.12

Hello devs, I'd like to include the fix for GEODE-782 [1] in release 1.12.0. During a refactor the default ack-wait-threshold was changed from 15 to 51. This will affect any deployment that doesn’t set its own threshold. The ack-wait-threshold determines how long we wait for a response to a

Re: test message - please ignore

got it... domain still looks weird On Fri, Feb 28, 2020 at 1:10 PM Bruce Schuchardt wrote: > I’m switching to a new email account. >

Re: [PROPOSAL] include GEODE-7829 in 1.12

bumping this out to DevList as something went wrong in the mail system... On 2020/02/28 19:27:42, Bruce Schuchardt wrote: > During a refactor the default ack-wait-threshold was changed from 15 to 51. > This will affect any deployment that doesn’t set its own threshold. > > The

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

+1 seems reasonable to do this for 1.12 and be ahead of the game, @Owen would you please spawn that as a separate release 1.12 thread? thanks, eB On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols wrote: > +1 > > We should have done this as soon as SSL/TLS was ready. Better late than > never! > >

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

-1 to limiting any tests... if there are issues with the tests let's fix that. we have too many commits coming in with little or no testing over new/changed code, so I can't see how removing any existing test coverage as a good idea Best, EB On Fri, Feb 28, 2020 at 10:58 AM Mark Hanson wrote:

Re: [PROPOSAL]: Include GEODE-7820 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7820: git cherry-pick -x ca7ccbce73d436005fe027f31ee910ee9beeb769 GEODE-7820 has been marked as 'resolved in' 1.12. Regards EB On Fri, Feb 28, 2020

Re: [PROPOSAL]: Include GEODE-7814 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7814: git cherry-pick -x db86faec699aca67c02325bca22dcd5b913ddfed GEODE-7814 has been marked as 'resolved in' 1.12. Regards EB On Thu, Feb 27, 2020

Re: [PROPOSAL] include GEODE-7796 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12.0 as the critical fix for GEODE-7796: git cherry-pick -x 71fafc83844d3c13a228c705d32df374e5630651 GEODE-7796 has been marked as 'resolved in' 1.12.0. Regards EB On Tue, Feb 18,

Re: [PROPOSAL]: Include GEODE-7756 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7756: git cherry-pick -x 5dd7a8420bbe43657abc82e5b8d073eb01b51d8d GEODE- has been marked as 'resolved in' 1.12. Regards EB On Thu, Feb 13, 2020

Re: [PROPOSAL]: Include GEODE-7789 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7789: git cherry-pick -x 71e156a55228d89efafd048e1533debba606c064 GEODE- has been marked as 'resolved in' 1.12. Regards EB On Thu, Feb 13, 2020

Re: Include GEODE-7776 in release 1.12

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7776: git cherry-pick -x 7ab2713d6c9d2d09a986513aaa18b333951fe61e GEODE- has been marked as 'resolved in' 1.12. Regards EB On Wed, Feb 12, 2020

Re: [PROPOSAL]: Include GEODE-7717 in Release 1.12.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7717: git cherry-pick -x bda6bdf50c0a6a3e7cc39fb3ff654a0c26c86d94 GEODE-7717 has been marked as 'resolved in' 1.12. Regards EB On Fri, Feb 7, 2020

Re: [Vote] Include GEODE-7752 into 1.12

errata On Fri, Feb 7, 2020 at 10:36 AM Ernest Burghardt wrote: > There appears to be consensus that this is a critical fix. > > The following commit has been brought into release/1.12 as the critical fix > for GEODE-7752: > > git cherry-pick -x 7028f601680fee3f57cbdff63951

Re: please include the fix for geode-7750 and geode-7760 in 1.12

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.12 as the critical fix for GEODE-7760: git cherry-pick -x af8307 GEODE- has been marked as 'resolved in' 1.12. Regards EB On Fri, Feb 7, 2020 at 9:07 AM Jinmei Liao wrote: >

Re: [Vote] Include GEODE-7752 into 1.12

marked as 'resolved in' 1.12. Regards EB On Wed, Feb 5, 2020 at 9:17 PM Udo Kohlmeyer wrote: > Hi there EB, > > fix has been merged to develop. (Everything is green now) > > 9c102e4f8836ca32ad51a05bbd4d0107e8fc0343 > > Thanks > > --Udo > > 0On 2/5/20 4:34 PM, Ernest

Re: [PROPOSAL]: Include GEODE-7728 in Release 1.12.0

at 4:32 PM Ernest Burghardt wrote: > +1 > > I'll plan to cherry-pick in the morning if there are no objections... > > > On Wed, Feb 5, 2020 at 11:20 AM Ivan Godwin wrote: > >> +1 >> >> On Wed, Feb 5, 2020 at 10:16 AM Nabarun Nag wrote: >> >

Re: [Vote] Include GEODE-7752 into 1.12

t passes all test requirements. > > --Udo > > > On 2/5/20 4:14 PM, Ernest Burghardt wrote: > > Udo, > > the PR has some failing tests that are in the "non-mandatory" category > for > > merge, TBH I'd prefer to have solid green changes being a

Re: [PROPOSAL]: Include GEODE-7728 in Release 1.12.0

+1 I'll plan to cherry-pick in the morning if there are no objections... On Wed, Feb 5, 2020 at 11:20 AM Ivan Godwin wrote: > +1 > > On Wed, Feb 5, 2020 at 10:16 AM Nabarun Nag wrote: > > > ++ > > > > On Wed, Feb 5, 2020 at 9:54 AM Alexander Murmann > > wrote: > > > > > +1 > > > > > > On

Re: [Vote] Include GEODE-7752 into 1.12

Udo, the PR has some failing tests that are in the "non-mandatory" category for merge, TBH I'd prefer to have solid green changes being added at this point forward... Thanks, EB On Wed, Feb 5, 2020 at 3:01 PM Alexander Murmann wrote: > Udo, you say "refactor", but this sounds more like a

Re: Release branch 1.12.0 created

CI is up and running now and I cherry-pick'd this commit. On Mon, Feb 3, 2020 at 11:13 AM Jinmei Liao wrote: > I just reverted a commit that I made last Friday, Please also include this > commit "16b296a4" in the release branch. Thanks! > > On Mon, Feb 3, 2020 at 11:

Release branch 1.12.0 created

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

[NOTIFY] Branch 1.12.0 to be cut February 3rd, 2020

Hello Geode, There have been no concerns expressed so we shall go forward with cutting the Geode 1.12 branch on February 3rd, 2020 - this makes it the Monday after the SuperBowl so please have a care this week to get any relevant PRs completed. There are many PRs in progress: (in various states

[DISCUSS] Cut 1.12.0 branch on February 3rd, 2020

Hello Geode, I'll be your release manager for Geode 1.12 and the plan is to cut the branch on February 3rd, 2020 (we'll avoid Groundhog Day and LeapDay as well...) As a reminder, only critical fixes will be allowed once the release branch is created, so it is helpful to have develop as stable as

Requesting permission to upload Apache Geode to Docker Hub

Hello Geode, I'll be the Release Manager for 1.12 and need permission to upload Apache Geode to Docker Hub. My DockerHub ID: eburghardt Thanks in advance, EB

Re: [VOTE] Apache Geode 1.11.0.RC4

+1 based on Dan's comments On Tue, Dec 24, 2019 at 11:17 AM Dan Smith wrote: > On Tue, Dec 24, 2019 at 10:12 AM Ernest Burghardt > wrote: > > > I also ran integrationTests locally (/gradlew integrationTest) on Mac and > > saw these failures > > > > It

Re: [VOTE] Apache Geode 1.11.0.RC4

built, ran unit tests, all good. I also ran integrationTests locally (/gradlew integrationTest) on Mac and saw these failures 43 tests completed, 36 failed > Task :geode-memcached:integrationTest FAILED > Task :geode-core:integrationTest

Re: [DISCUSS] `status locator` command fail when locator's ssl is turned on

I like the approach Jens is suggesting, seems intuitive to me On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe wrote: > So it seems that the situation is something like this where I'm able to > make the initial connection but then retrieving status fails: > > gfsh>connect

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

I'm a proponent of using squash-and-merge, and once a person has chosen this option once it comes up by default afterwards... Owen, I don't think you have consensus to put forth this PR, there are -1s above... (early voting) maybe we'll be better off socializing the norm of squash-and-merge and

Re: [DISCUSS] - Move gfsh into its own submodule

+1 On Fri, Nov 22, 2019 at 8:41 AM Jens Deppe wrote: > Hello All, > > We'd like to propose moving gfsh and all associated commands into its own > gradle submodule (implicitly thus also producing a separate maven > artifact). The underlying intent is to decouple geode core from any Spring >

Re: Odg: bug fix needed for release/1.11.0

we could just use GMT (Geode Mean Time) On Wed, Nov 6, 2019 at 9:45 AM Mark Hanson wrote: > 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: > > > >

Re: [DISCUSS] Blocking merge button in PR

gt; If we are seeing that our committers merge without sufficient review >> > (via >> > >> human or automated means), is this an education problem we can solve? >> > >> >> > >> On Mon, Oct 21, 2019 at 10:18 AM Udo Kohlmeyer >> wrote: >&g

Re: [DISCUSS] Blocking merge button in PR

+1 to enacting this immediately... just this weekend a PR was merged with failures on all of the following: * concourse-ci/DistributedTestOpenJDK11 * Concourse CI build failure * concourse-ci/UnitTestOpenJDK11 * Concourse CI build failure * concourse-ci/UnitTestOpenJDK8 * Concourse CI build

Re: [DISCUSS] Blocking merge button in PR

ky" are > > test problems. In the last few months I've fixed product problems that > > were hit by supposedly "flaky" tests. Those tests were just unable to > > reproduce the product problem 100% of the time. A flickering test > > doesn't always mean it's a pr

Re: [DISCUSS] Blocking merge button in PR

I had one recently that was Approved and I merged pre-maturely and had to be reverted: d63638e4654bc6c71a232838b745dec6ef476ec9 Subsequently I have run into some test flakiness, but if a PR submitter has a pre-checkin failure it could be tricky to tell that its a Flaky situation... In my last go

Re: [DISCUSS]: Commit Message Format too Short?

back to Juan's original point: (I think this was anyway) +1 to details and more details on the commit message and if removing pedantic guidelines and just using tooling to word wrap will encourage better communication via better commit messages On Tue, Oct 8, 2019 at 8:33 AM Owen Nichols wrote:

Re: [DISCUSS]: Commit Message Format too Short?

Isn't this only regarding the "headline" commit message, but there can be sub-bulletted text further describing the commit in greater detail...? This is how I have always interpreted this business... EB On Tue, Oct 8, 2019 at 3:58 AM Alberto Bustamante Reyes wrote: > I think its a good idea to

[DISCUSS] Logging module separation

Dear Geode, In support of the Membership modularization efforts, we would like to move some of our logging code that wraps log4j into a separate module is needed in order to break

Re: Wiki write access needed

got it, thanks!!! On Thu, Sep 5, 2019 at 11:01 AM Dan Smith wrote: > Ok, you should have access now. > > -Dan > > On Wed, Sep 4, 2019 at 5:01 PM Ernest Burghardt > wrote: > > > echobravo > > > > On Wed, Sep 4, 2019 at 4:43 PM Dan Smith wrote: >

Re: Wiki write access needed

echobravo On Wed, Sep 4, 2019 at 4:43 PM Dan Smith wrote: > What's your username on the wiki? > > -Dan > > On Wed, Sep 4, 2019 at 4:36 PM Ernest Burghardt > wrote: > > > Hello, > > > > May I please have write access to the wiki? > > > > Thank you, > > EB > > >

Wiki write access needed

Hello, May I please have write access to the wiki? Thank you, EB

Re: [DISCUSS] Time to cut Geode 1.10.0?

There is a PR #3844 up to address GEODE-7012 I think this should be in the next release... EB On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann wrote: > *Cutting the release* > Do we have any

Re: [DISCUSS] Adoption of a Coding Standard

Here's some food for thought on creating coding standards... 1. You can't please everyone all of the time or in all aspects and this becomes "Hero" driven or a "holy war" 2. Creating a custom standard is very time/resource consuming and (see #1) 3. Adopting an objectively maintained industry

Re: Unnecessary uses of final on local variables

+1 to auto-enforcement (if possible) post-consensus On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala wrote: > final in Java does not guarantee immutability. It would be AWESOME if it > did but all it guarantees is that the variable cannot be reassigned. In > most cases the variable points to an

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

Yes make them gating. Run them every commit, Windows is a supported platform. Red boxes get attention and Red boxes get fixed. EB On Thu, May 16, 2019 at 1:09 AM Udo Kohlmeyer wrote: > I think we need to make sure our windows tests get to green... If we > make them gating then we will never

Re: [DISCUSS] Disable merge for failing pull requests

+1 to blocking the "merge" button On Mon, Nov 19, 2018 at 5:09 PM Udo Kohlmeyer wrote: > I don't believe "name and shame" is a hammer we should wield, but if we > have use it... use it wisely > > Could one not configure the button that the owner of the PR cannot merge > the PR? > > --Udo > > >

Re: [VOTE] Apache Geode 1.8.0 RC2

Maybe native should too. > > > > > On Dec 11, 2018, at 6:47 AM, Ernest Burghardt > > wrote: > > > > > > If the community desires the default dev version to match the release, > > > let's file a JIRA and change this... anyone else have an opinion

Re: [VOTE] Apache Geode 1.8.0 RC2

If the community desires the default dev version to match the release, let's file a JIRA and change this... anyone else have an opinion on this default version? Thanks! EB On Mon, Dec 10, 2018 at 10:28 PM Jacob Barrett wrote: > -0 > > I don’t think a user should have to specify a version when

Re: [VOTE] Apache Geode 1.8.0 RC1

for geode-native following Building.md is a good verfication On Mon, Dec 3, 2018 at 11:02 AM Nabarun Nag wrote: > Thank you Alexander and Anthony for the explanation. > I am sorry for missing the signature checks for the apache geode src. :( > Was able to build and run geode-native code. > >

GEODE Slack?

Hi Geode, Will there be a GEODE Slack in the near future? Thanks, EB

Re: Geode Native & Apache Geode 1.8 Release

>> > >> >> On Thu, Oct 11, 2018 at 3:23 PM Dan Smith wrote: > >> >> > >> >>> +1 for a source release. Awesome! > >> >>> > >> >>> -Dan > >> >>> > >> >>> On Thu, Oct 11,

Re: [DISCUSS] Cutting 1.8 release branch

and PR 390 has been approved and merged On Thu, Nov 1, 2018 at 5:10 PM Ernest Burghardt wrote: > geode-native fixes are in https://github.com/apache/geode-native/pull/390 > > On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote: > >> The geode-native source headers I men

Re: [DISCUSS] Cutting 1.8 release branch

geode-native fixes are in https://github.com/apache/geode-native/pull/390 On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote: > The geode-native source headers I mentioned in [1] need to be cleaned up. > > Anthony > > [1] >

Re: Geode Native & Apache Geode 1.8 Release

+1 for a source release On Wed, Oct 10, 2018 at 12:59 PM Anthony Baker wrote: > I think starting with a source-only release of the native client is a good > first step. That lets us focus on verifying that all the tasks outlined in > [1] are complete and correct. > > Anthony > > [1]

Re: GitHub PR notifications

+1 for lowering SPAM On Thu, Aug 23, 2018 at 9:19 PM, Jacob Barrett wrote: > Must we get spammed with every thing that happens? It seems to me a log in > GitHub, JIRA and email is obscene. > > All this email we get now just gets bulk deleted and I often miss > important conversations. If we

[DISCUSS] Streamline return value from RemoteQuery

Currently, geode-native's query::execute returns a shared_ptr and that pointer can be either ResultSet or StructSet. RemoteQuery::execute contains logical code to determine with QueryResults are greater than 0... We should look at removing this logic and only returning StructSets This allows

Re: trying to implement SSL configuration

Hello, For "native" C++ interaction have a look at geode-native/cppcache/integration-test/testThinClientSSL This should provide an example of connecting with SSL enabled... EB On Tue, Jun 12, 2018 at 2:48 AM, Liron Ben Ari wrote: > > We check - the PKCS12 works - (as we saw it in the

Re: [DISCUSS] New List for Commit and CI Emails

+1 for less noise and spam On Wed, Mar 21, 2018 at 11:56 AM, Galen O'Sullivan wrote: > Yeah, I think I'm sending myself convinced by Swapnil's argument. > > How about muting the "nightly build succeeded" email? > > On Wed, Mar 21, 2018 at 9:58 AM, Sean Goller

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

+1 "To be consistent with our Java brothers I would suggest apache::geode::client::internal namespace and headers located in the include/geode/internal directory." On Wed, Dec 27, 2017 at 4:28 PM, Mark Hanson wrote: > Sounds good to me. +1 > > Thanks, > Mark > > On Dec 27,

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

+1 for removal On Thu, Nov 16, 2017 at 1: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

Re: [Discussion] Native - Should C++ client support wchar_t type?

+1 for removal On Fri, Oct 27, 2017 at 10:03 AM, Michael William Dodge wrote: > I think support for wchar_t adds unnecessary complexity and should be > removed. > > Sarge > > > On 26 Oct, 2017, at 13:05, Jacob Barrett wrote: > > > > I think we should get

Re: [Discussion] Native Region::registerAllKeys

+1 for aligning APIs On Mon, Oct 23, 2017 at 11:35 AM, Jacob Barrett wrote: > This function has an optional out variable to capture the list of keys that > get registered in this function. There are no tests that test the behavior > of the function where the out variable is

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

+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 Java API > > Sarge > > > On 23 Oct, 2017, at 09:32, Jacob Barrett wrote: > > > > As part of our decision to

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

+1 Tuple On Wed, Oct 4, 2017 at 7:58 AM, David Kimura wrote: > +1 > > On Tue, Oct 3, 2017 at 5:45 PM, Hitesh Khamesra > > wrote: > > > Tuple option. > > > > Sent from Yahoo Mail on Android > > > > On Tue, Oct 3, 2017 at 4:27 PM, Jacob

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

Currently we have a mix of the counter argument... we use return values and you have to call the explicitly named methods: double* readDoubleArray(const char* fieldName, int32_t& length) int64_t* readLongArray(const char* fieldName, int32_t& length) I'm good with non-const refs in-out to the

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

rote: > > > > > >> Late to this party. > > >> > > >> Confession 1: I had to look up both RVO and copy-elision. > > >> Confession 2: I don't like using pointers at all. I used to, but I've > > >> evolved to just use C# and Java :) > > >

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

okay so we have +1s on object.toString() any dissenting opinions? On Fri, Sep 15, 2017 at 11:52 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt <eburgha...@pivotal.io> > wrote: > > > Not convinced or grok'g doing b

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

+1 for const PdxReader - remember, vote early and vote often... On Fri, Sep 15, 2017 at 11:40 AM, Mark Hanson wrote: > Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr > input); > > Hi All, > > So there is a question outstanding about whether or not

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

Not convinced or grok'g doing both... what is the benefit of adding the std::to_string()'s? On Fri, Sep 15, 2017 at 11:46 AM, Jacob Barrett wrote: > On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson wrote: > > > class blobject > > { > > bool blobBool; > >

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

cool that we could export into the std namespace, but as a library I don't think it is a good idea as a user of our library might have done the same thing and that is a situation we can easily/pro-actively avoid +1 object::toString() On Fri, Sep 15, 2017 at 11:33 AM, Mark Hanson

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

+1 Approach 1) std::string str = object.to_string(); On Fri, Sep 15, 2017 at 11:18 AM, Mark Hanson wrote: > So we have two approaches as their has been a veto on w_string, so it will > not be used. > > Approach 1) std::string str = object.to_string(); > Approach 2)

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

e in the philosophy of using as few as > >> possible and using inheritance to drive specificity. The benefit is that > >> the code can be as simple or as complex as it can be without unnecessary > >> overhead e.g error => network error => tcp error. So, I may jus

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

Calling a vote for: - Raw pointer - shard pointer +1 raw Pointer, I had to look up RVO and am new to std::move(s) On Thu, Sep 14, 2017 at 3:02 PM, Michael William Dodge wrote: > I generally dig reference-counted pointers for avoiding lifetime issues > with objects allocated

Re: [DISCUSS] Change signature of Serializable::fromData on Geode-Native

+1 cleans up the public API and code using this as you can see in the proposed changes on Jake's fork On Wed, Sep 13, 2017 at 3:30 PM, Jacob Barrett wrote: > I would like to propose a change: > Serializable* Serializable::formData(DataInput& in) > to > void

Re: [VOTE] Apache Geode release - v1.2.1 RC3

+1 for always only shipping from a green CI On Wed, Sep 13, 2017 at 11:22 AM, Dan Smith wrote: > The jenkins build had failures for this revision. They look like they might > be environmental issues but I don't think we should actually ship this > unless we have a green

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

if we continue the merging of Jake <> Sarge comments we might find that std::exception(s) is sufficient if the many name exceptions that pertain to the Library are all handled in a similar manner and only have unique names for human readability, but not a functional consideration... EB On Fri,

Re: Missing Gitbox activation email

When geode-native moved I don't think we received an activation email... just had to follow the instructions Jake sent out: (obviously drop the "-native") For committers the origin is now github.com/apache/geode-native. Before you can get write access to the new repo you need to "link" your

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

I really like the Fluent pattern as it is done in C# and Java... I'm not sure the juice is worth the squeeze in an existing c++ library. I do agree we should normalize our factory/builder patterns. On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett wrote: > Mark, > > I

Re: [Discuss] What type should C++ object creation functions return?

std::unique_ptr looks like a good option. then again if the typical usage is like so: cachePtr = CacheFactory::createCacheFactory(pp)->create(); it seems simple enough to just return the bare object EB On Wed, Sep 6, 2017 at 1:27 PM, David Kimura wrote: > What type

Re: Gitbox enables the full GitHub workflow

+1 On Tue, Aug 22, 2017 at 12:28 PM, Joey McAllister wrote: > +1 > > On Tue, Aug 22, 2017 at 11:28 AM Ken Howe wrote: > > > +1 Yes, let’s make the move > > > > > On Aug 22, 2017, at 11:21 AM, Nabarun Nag wrote: > > > > > > +1 > > > >

Re: Gitbox enables the full GitHub workflow

Mark, Go ahead and file it and geode-native will be the canaries... Thanks, Ernie On Mon, Aug 14, 2017 at 2:16 PM, Mark Bretl wrote: > Since we have people wanting this and need a small experiment group to > blaze the trail for us, I think the geode-native would be a good

Re: []DISCUSS] Using package names to identify public API's

+1 for protobuf being internal as they are not intended to be first class OO citizens you can read more about there here (the same warning exists for all supported languages btw) On Fri, Aug 11, 2017 at 12:34 PM, Michael William

Re: Gitbox enables the full GitHub workflow

+1 On Wed, Aug 9, 2017 at 2:57 PM, Nabarun Nag wrote: > +1 > > will this allow us to choose reviewers while creating PRs on github now? > > Regards > Nabarun > > On Wed, Aug 9, 2017 at 1:19 PM Udo Kohlmeyer > wrote: > > > +1 > > > > > > On 8/9/17 12:56,

Re: [DISCUSS] Feature branch cleanup

+1 to using your own fork for feature work On Wed, Aug 2, 2017 at 10:58 PM, Jacob Barrett wrote: > Along those same lines it would be really nice if people would use their > own forks for feature branches, then we wouldn't have this mess at all. > > Sent from my iPhone > >

Re: Geode-Native Windows build

Hi Daniel, Would you please share your config step command line? EB On Wed, Jul 12, 2017 at 7:52 AM, Daniel Farcovich < daniel.farcov...@amdocs.com> wrote: > Hi, > I'm failing to build geode native cpp client on windows, although followed > the instructions on BUILDING.md > Looks like there

Re: [VOTE] Using Pull Requests over Review Board

+1 for PRs in Github - one place, simple On Wed, Jun 14, 2017 at 9:17 AM, Kenneth Howe wrote: > -1 per my comments on the [DISCUSS] thread > > > On Jun 11, 2017, at 9:51 AM, Jacob Barrett wrote: > > > > After a few days of discussion [1] this thread has

  1   2   >