Re: Geode Version in the logs

Just in case you are planning to write tests consisting of multiple versions of Apache Geode simultaneously, you can look into any RollingUpgradeDUnitTest. Those append the version number before each log statement. Regards Nabarun Nag On Thu, Jan 3, 2019 at 8:53 AM Jacob Barrett wrote: > Gi

Re: Extremely long IntelliJ Gradle refresh times

I have not experienced this but , for it does take a long time (but not 60min) after an IntelliJ update or invalidating IntelliJ caches. That time it indexes all the Java , maven and gradle caches , sources and jars. Subsequent refreshes are faster. Also increasing IntelliJ memory to 8g helps. Re

Re: Very red CI -> Hold merges, please

FYI, I have just merged a ci timeout fix to increase the timeout for geode-benchmarks to 4h. This does not influence any geode modules. Regards Naba On Thu, Feb 7, 2019 at 9:32 AM Alexander Murmann wrote: > Hi folks, > > Our CI is very red since ~24 hours > < > https://concourse.apachegeode-ci.

Re: Geode 1.9 Release Manager

I think also GEODE-6391, which is to fix a NPE while propagating región destroy and invalidate region messages. Regards Naba On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh wrote: > I think Kirk's topic and any solution related to stats (int to long) should > be resolved before cutting the branch?

Re: Geode 1.9 Release Manager

I agree with the cutting the release branch, keep it sanitized from additional commits going into develop but ensure only these important critical fixes mentioned above in this chain makes it into the release branch. For the second part, I am not sure how it was determined that fixes for GEODE-639

Re: Geode 1.9 Release Manager

I could not find any DISCUSS mails about not blocking a release. I may be wrong, I apologize for that but could point me to the mail / documentation about the release management. Regards Naba On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda wrote: > Did we not agreed that we won't be blocking a

Re: Geode 1.9 Release Manager

less likely, but not remove the risk entirely. > > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag wrote: > > > I could not find any DISCUSS mails about not blocking a release. I may be > > wrong, I apologize for that but could point me to the mail / > documentation > >

Re: Geode 1.9 Release Manager

se branch. > > On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag wrote: > > > I agree but not putting in these fixes means that we are releasing with > > serious known issues in the product. Hence in my opinion this risk is > > acceptable. > > > > Regards > > N

Re: [VOTE] Apache Geode 1.9.0 RC4

e-native-1.9.0-src.tar.gz > gpg: Signature made Fri Apr 19 16:25:20 2019 PDT > gpg:using RSA key DB5476815A475574577D442B468A4800EAFB2498 > gpg: Good signature from "Owen Nichols " [full] - Regards Nabarun Nag On Wed, Apr 24, 2019 at 8:36 AM Ryan McMahon wrote: > +1 Verified signatures,

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

exception class name. Regards Nabarun Nag On Tue, May 28, 2019 at 3:08 PM Owen Nichols wrote: > This example came from https://issues.apache.org/jira/browse/GEODE-6796 > in which the submitter assumed that Geode was deliberately emitting a > poorly-worded and confusing error message. >

Re: [DISCUSS] require reviews before merging a PR

Hi, I personally feel the same as how Bruce feels. - This will make life harder / inconvenient. - One approval from a person who is experienced in that part of code is more than enough for me. - The workload on the Geode developers is already too high, it is unfair to burden then with more task

Re: [DISCUSS] require reviews before merging a PR

Hi, I agree with Dan, I would like to follow what he has suggested. Also, I will not mind anyone following the 3 reviewers for everything if they chose to do so. Just please don't make it blanket rule. Regards Naba PS: I found this filter on github to look up PRs that I have reviewed till date /

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

In my opinion, I am okay will multiple commits within a PR. But please do squash them to a single commit when it is pushed to develop. This helps us a ton if it is single commit. - bisect operations are easier when it is a single commit during major failure analysis. - cherrypick is easier when it

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

commit log with "contextually irrelevant" noise. (also > makes it harder to follow all the changes that are in a branch). What if > I want to rollback a commit into develop, how many does one have to > revert, 1 is always simpler than 2-10... Also.. cherry picking becomes > sim

Re: [DISCUSS] Time to cut Geode 1.10.0?

, where we involved the entire community in its development, phase by phase. The wiki is up and running, if someone has any concerns can raise it as a JIRA or comment in the wiki and the community as a whole can decide if it is a valid concern or not and act upon it. Regards Nabarun Nag On Fri

Re: New release branch for Apache Geode 1.10.0

develop. We need to hold any pipeline testing on the branch till this fix is in. Regards Nabarun Nag On Fri, Aug 2, 2019 at 11:17 AM Dick Cavender wrote: > Hello Geode Dev Community, > > We have created a new release branch for Apache Geode 1.10.0 - > "release/1.10.0" &g

Re: New release branch for Apache Geode 1.10.0

ci.info/teams/main/pipelines/apache-release-1-10-0-main > > > >> is all green. Perhaps one way to convince the Geode community that your > >> fix satisfies the “critical fixes” rule might be to share a link to a > >> github commit adding tests that expose the iss

Re: [DISCUSS] Time to cut Geode 1.10.0?

t;>> I'll take on the Release Manager role for Geode 1.10 with the > >> 1.9.0 > >>>>>>>> release > >>>>>>>>> manager's help (Owen:). > >>>>>>>>> > >>>>>>>>> I&#

Re: [DISCUSS] Time to cut Geode 1.10.0?

sume that it was introduced by the following commit. GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r… (#3853) We are planning to revert this commit in the release branch as this is a necessary fix that needs to be in the release. Regards Nabarun Nag On Tue, Aug 6, 2019

Re: [DISCUSS] Time to cut Geode 1.10.0?

Hi, The commit mentioned in the earlier email has now been reverted on develop and release/1.10.0 branches. Thank you for your patience. Regards Nabarun Nag On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag wrote: > Hi Geode Community, > > After some further analysis, few of the threads ar

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 On Thu, Aug 15, 2019 at 10:15 AM Alexander Murmann wrote: > +1 > > Agreed to fixing this. It's impossible for a user to discover they hit an > edge case that we fail to support till they are in prod and restart. > > On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos > wrote: > > > Hello Udo, >

Re: Propose fix for 1.10 release: Export offline data command failed with EntryDestroyedException

+1 On Fri, Aug 16, 2019 at 2:45 PM Anilkumar Gingade wrote: > +1 to include > > On Fri, Aug 16, 2019 at 2:41 PM Anthony Baker wrote: > > > +1 from me. When you need to do an offline export, it’s usually > > important. Not being able to export *all* the data might lead to data > loss. > > > >

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

Hi Anil, Will it be possible to explain to the community how the starting AEQ in a paused state is different from creating gateway senders with manual start set to true. It may be of concern as 'manual start' for gateways is a deprecated. Just thinking out loud, will it be more feasible if we c

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

+1 This will be a good inclusion in Apache Geode 1.10.0 release. Regards Naba On Mon, Aug 26, 2019 at 3:36 PM Jacob Barrett wrote: > +1 > > Thanks for the details! > > > On Aug 26, 2019, at 3:33 PM, Ryan McMahon wrote: > > > > Udo, > > > > Here are inline answers to your questions: > > > > *I

Re: [VOTE] Apache Geode 1.10.0.RC1

this is harmless or has some adverse consequences. I would like to know why it's designed this way. Regards Nabarun Nag On Wed, Sep 4, 2019 at 4:14 PM Dick Cavender wrote: > We manually signed the apache-geode-1.10.0-src.tgz dist and uploaded the > asc file. > > Unclear on why

Re: [VOTE] Apache Geode 1.10.0.RC1

> the call stack. If it is still failing for you I recommend getting a fresh > clone of geode and then repeat the above steps. > > Thanks, > Kirk > > On Thu, Sep 5, 2019 at 10:16 AM Nabarun Nag wrote: > > > Hello, > > > > I was able to notice that afte

Re: [VOTE] Apache Geode 1.10.0.RC1

; > < org/apache/geode/internal/cache/EvictionAttributesImpl,false > > 276d270 > > < org/apache/geode/internal/cache/PartitionAttributesImpl,false > > 517d510 > > < > > > > > org/apache/geode/management/internal/cli/functions/CacheRealizationFunctio

Re: [VOTE] Apache Geode 1.9.1.RC3

Can anyone confirm that the native client test failure happening in 1.10 RC does not occur in this candidate. I can test it if someone can point me to the instructions to do that. Regards Naba On Fri, Sep 6, 2019 at 8:38 AM Robert Houghton wrote: > +1 given the pre-existence of threw class pa

Re: [VOTE] Apache Geode 1.10.0.RC1

and.getOperation(BaseCommand.java:1466) > >>> > >>> at > org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114) > >>> > >>> at > org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183) &

[VOTE] Adding new AEQ feature to release/1.10.0

Will create a PR ASAP. Regards Nabarun Nag

Re: [VOTE] Adding new AEQ feature to release/1.10.0

> > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > On Fri, Sep 13, 2019 at 3:25 PM Anilkumar Gingade < > > > aging...@pivotal.io > > > > > > > > > > > wrote: > &

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

+1 On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: > I want to merge GEODE-7208, which is lucene specific fix > > The fix will enable indexing on inherited attributes in user object. > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > Regards > Gester >

Re: [DISCUSS] - Cutting of release 1.9.2

Just out of curiosity, do we have preliminary tests done to ensure that all the tasks under GEODE-7121 are enough to implement the solution by Spring Data Gemfire to solve the deadlock issue? +1 to include the fix. On Fri, Sep 20, 2019 at 1:13 PM John Blum wrote: > +1 for releasing Apache Geode

[DISCUSS] Blocking merge button in PR

till all tests are done? Regards Nabarun Nag

Re: [DISCUSS] Blocking merge button in PR

R > >> checks, which then broke the build? > >> > >> At last discussion, one concern raised was providing a way that anyone > in > >> the community could re-trigger a failed PR check if it hit an unrelated > >> flaky failure. > >> > >> Let’s be

Re: [DISCUSS] Blocking merge button in PR

; > >>>> On 10/18/19 12:46 PM, Ernest Burghardt wrote: > >>>>> I had one recently that was Approved and I merged pre-maturely and > >> had > >>> to > >>>>> be reverted: d63638e4654bc6c71a232838b745dec6ef476ec9 > >>>>

Re: [DISCUSS] Blocking merge button in PR

@Karen Thank you so much for the feedback. I understand that committers must trust each other and I agree entirely with that. This proposal is just preventing us from making mistakes. Its just guard rails. As you can see in the email chain that this mistake was made multiple times and this has let

Re: [DISCUSS] Blocking merge button in PR

> again, the masses are impacted due to a few. > > > > Thank you Naba for following this through. > > > > --Udo > > > > On 10/21/19 11:05 AM, Nabarun Nag wrote: > > > @Karen > > > > > > Thank you so much for the feedback. I unders

Re: [DISCUSS] Blocking merge button in PR

0/21/19 3:04 PM, Ernest Burghardt wrote: > > > +1 > > > @Naba thanks for seeing this through! > > > > > > On Mon, Oct 21, 2019 at 1:51 PM Nabarun Nag wrote: > > > > > >> Thank you all for all the valuable feedback. Robert was kind enough to &

Re: [DISCUSS] Blocking merge button in PR

; > On Oct 21, 2019, at 11:38 AM, Anthony Baker wrote: > > > > +1, very well said > > > > Anthony > > > >> On Oct 21, 2019, at 11:05 AM, Nabarun Nag wrote: > >> > >> > >> > >> *Reiterating the proposal:* > >> Gi

[REQUEST] Squash merge please

Hi Geode Committers, A kind request for using squash commit instead of using merge. This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger

Re: Please review PR #4188

Hi Mario, Please use the squash and merge button while merging PRs. This will help us in detecting regression/flakiness failures faster. A previous email stating why it was needed was sent to the dev list. Regards Naba On Mon, Oct 21, 2019 at 11:05 PM Mario Ivanac wrote: > Hi, > > could somo

Fwd: [PSA] Github branch protection

Hi, Geode dev Community, This is an announcement that the GitHub branch protection rules are *now active* on develop branch for Apache Geode. The following rules are currently active : - Require pull request reviews before merging - at least 1 - Require status checks to pass before merging [

Re: [PSA] Github branch protection

quest for changes will now > completely > > block merging the PR. I'm not certain this was intentional? One rogue > > developer could block the merging of any or every PR. I'm not sure one > > person should have that much power... > > > > On Thu, Oct 24, 201

Re: [PSA] Github branch protection

er the impression that they were not the same thing. > > @Helena Thanks! I didn't know that was possible. > > - Aaron > > > On Thu, Oct 24, 2019 at 3:02 PM Nabarun Nag wrote: > > > @Aaron : which PR are you referring to? I can only see "GEODE-7326: Add > > cac

Re: [PSA] Github branch protection

Edit: Helena has mentioned that a review can be dismissed. [spelling mistake] On Thu, Oct 24, 2019 at 4:35 PM Nabarun Nag wrote: > Hi Aaron / Kirk, > > Thank you for the update. As Owen has mentioned that if there is a change > request from someone with write permission to th

Re: [DISCUSS] Tweak to branch protection rules

+1 On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider wrote: > +1 > > On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols wrote: > > > +1 …this has already bitten me a few times > > > > > On Oct 29, 2019, at 6:01 PM, Dan Smith wrote: > > > > > > Hi all, > > > > > > It seems we've configured our branch

Re: [DISCUSS] Tweak to branch protection rules

requested changes or not)?. > > If the answer to the above is "yes", then +1. > > > > On Wed, Oct 30, 2019 at 1:44 AM Nabarun Nag wrote: > > > > > +1 > > > > > > On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider < > dschnei...@pivotal.i

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

for unit tests and build to be successful. Regards Nabarun Nag On Wed, Oct 30, 2019 at 11:32 AM Aaron Lindsey wrote: > One case when it might be acceptable to overrule a PR check is reverting a > commit. Before the branch protection was enabled, a committer could revert > a commit withou

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi Udo +1, 5.2.0.RELEASE to be specific? On Wed, Oct 30, 2019 at 11:04 AM Ju@N wrote: > Hello Udo, > > Big +1 for the proposal!. > That said, I believe it was agreed a couple of months ago in the > *Lightweight > RFC Process [1] *that the whole discussion should be done in the [DISCUSS] > email

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi Udo, Maven has the latest as 5.2.0.RELEASE as the latest version. In the Dependency.groovy file, we have been putting the full version number. Hence I am guessing you are suggesting we put 5.2.0.RELEASE? What about the status of the following dependencies? 'org.springframework.hateoas', name:

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

Will breaking this PR into parts help. Put the tests in separate PRs? +1 if it is inconvenient On Thu, Oct 31, 2019 at 2:52 PM Donal Evans wrote: > +1 to allowing this PR to be merged, although I'd lean strongly toward > facilitating this by temporarily increasing the timeout on the job to allo

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

ble options had > been > > >>>>>> exhausted (reworking or splitting up the PR, pushing empty > commits, > > >>>>>> rebasing the PR, etc) > > >>>>>> > > >>>>>>> On Oct 30, 2019, at 1:42 PM, Dan Smi

Re: unable to push

Hi Bruce, This was what was discussed in multiple email chains last week. GitHub branch protection was enabled on the develop branch. Command-line and the merge button on the website have the same effect. This has now being implemented in a lot of Apache projects and we are implementing it as the

Re: Re: unable to push

and was approved > couldn't be pushed from the command line Naba > > On 10/31/19 5:11 PM, Nabarun Nag wrote: > > Hi Bruce, > > > > This was what was discussed in multiple email chains last week. GitHub > > branch protection was enabled on the develop branch. >

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

> > > looking to use the latest version and it's associated BOM. > > > > > > > > That might be inclusive of other Spring project upgrades. > > > > > > > > --Udo > > > > > > > > On 10/30/19 1:35 PM, Nabarun Nag w

Re: Odg: gateway sender queue

+1 to Dan's suggestion What about a log and a vsd stat in the gfs file which tells us if any cleanQueue commands were executed. Regards Nabarun Nag On Thu, Nov 14, 2019 at 10:27 AM Udo Kohlmeyer wrote: > In addition... making is default has bigger consequences that we have >

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

+1 On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer wrote: > Thank you for this Bill, > > I must admit that I'm starting to get a feeling of "scope creep" here.. > I understand that all efforts to "modularize" membership would require > some form of peripheral decoupling. > > BUT > > I'm starting t

Re: [VOTE] Fix bad-merge of GEODE-7488

+1 On Fri, Nov 22, 2019 at 12:00 PM Anthony Baker wrote: > Clearly the right thing to do is fix it. VOTE not needed IMO. > > Anthony > > > > On Nov 22, 2019, at 11:55 AM, Robert Houghton > wrote: > > > > I was overzealous in a merge to Geode, and got us into a chicken-and-egg > > issue for PRs

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

Just out of curiosity, why did the PR checks for GEODE-7488 not fail and allowed it be merged? Is something lacking in our testing? On Fri, Nov 22, 2019 at 12:19 PM Dan Smith wrote: > On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols wrote: > > > Tallying the votes from this thread, it looks like t

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

+1 On Fri, Nov 22, 2019 at 12:51 PM Charlie Black wrote: > this proposal == awesome sauce > > +1 > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton > wrote: > > > +1 > > > > Do we want to restart from my lazy POC from a few months ago? > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe wrote: >

Re: [REQUEST] Squash merge please

wrote: > -1 I really like to sometimes have more than 1 commit in a PR and keep them > separate when they merge to develop > > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag wrote: > > > Hi Geode Committers, > > > > A kind request for using squash commit instead of

Re: [REQUEST] Squash merge please

uld be hard to see the actual change. If split out, it's beautiful > and > > crystal clear. > > > > I am unsure how that would be reflected in terms of JIRA ticket > references. > > Usually we assume that if there is a commit with the ticket number, the > > issue

Re: [REQUEST] Squash merge please

onality change. If that was in one > commit, > >> it would be hard to see the actual change. If split out, it's beautiful > and > >> crystal clear. > >> > >> I am unsure how that would be reflected in terms of JIRA ticket > references. > >&

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

;>> * > >>>>>> > >>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in > >>>>>> the commit message? > >>>>>> > >>>>>> * > >>>>>> > >

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

so for the record, I've been working on Geode since the > beginning > >>>>>> and I > >>>>>>>> was never made aware of this change in our process. I never voted > on > >>>>>> it. > >>>>>>>> I'm not a b

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

izing the norm of squash-and-merge > and > > >>> gaining a natural consensus that way... > > >>> > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols > > >> wrote: > > >>> > > >>>> The proposed action manifests as

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

ink 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 > > >>> gaining a natur

Re: [DISCUSS] abandon branch protection rules

Please maintain the branch protection rules. Waiting for reviews and Unit tests to pass does not stifle productivity, but prevents us from making mistakes that are detrimental to the entire community. If I am not mistaken, we still have pushed code which broke builds and regressions. I would sugges

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

eason). Regards Nabarun Nag On Tue, Dec 31, 2019 at 5:32 PM Dan Smith wrote: > Some of these test have been ignored for a long time. However, looking at > the history, I see we have ignored some tests as recently as in the last > month, for what seem like some questionable reasons. > >

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

; >>> We now have commits on develop that don’t compile. For example: > >>> > >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6 > >>> ./gradlew devBuild > >>> ...spotlessJava FAILED > >>> We implemented branch p

Re: WAN replication issue in cloud native environments

Hi Alberto, Thank you for the contributions to the Apache Geode project Here are a few feedback and pointers that we came up with: 1. Right now looking at your solution, we can see that you are modifying the class "ServerLocation" which is used to stored as a key in the connectionMap in LocatorLo

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

++ On Wed, Feb 5, 2020 at 9:54 AM Alexander Murmann wrote: > +1 > > On Wed, Feb 5, 2020 at 9:29 AM Udo Kohlmeyer wrote: > > > +1 - for inclusion > > > > On 2/5/20 4:22 AM, Ju@N wrote: > > > Hello devs, > > > > > > I'd like to include the fix for GEODE-7728 [1] in release 1.12.0. > > > The chang

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

+1 On Thu, Feb 13, 2020 at 2:09 AM Ju@N wrote: > Hello devs, > > I'd like to include the fix for GEODE-7789 [1] in release 1.12.0. > The change prevents a performance degradation introduced in Geode 1.11, it > basically shows up on clusters where there's at least one client with > subscription e

[ANNOUNCE] geode-kafka-connector

certified. We will highly appreciate any feedback and contributions from the community. Please do reach out to us if you have any questions or concerns. We will reach out to the community when we are ready with the first release. Regards Nabarun Nag

[ANNOUNCE] OQL Method Invocation Security

ce/display/GEODE/OQL+Method+Invocation+Security Regards Nabarun Nag

OQL Method Authorizer Blog

Hi Geode Community, Please do visit the blog that Juan Ramos has put up on the OQL Method Authorizer : https://jujoramos.blogspot.com/2020/02/pluggable-oql-method-authorization.html Thank you Juan for this effort. Regards Nabarun Nag

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

What help is needed in this effort? Regards Naba On Fri, Feb 28, 2020 at 11:35 AM Mark Hanson wrote: > Alright, so basically it seems like people are not ok with the not > requiring stressnewtest approach. So I guess that means that we need to > identify -1s willing to help resolve this problem

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

+1 On Fri, Mar 6, 2020 at 6:33 PM Donal Evans wrote: > With fairly apt timing, we've recently had a PR merged ( > https://github.com/apache/geode/pull/4745) that introduced a test that has > resulted in fairly consistently flaky failures in the pipeline (JIRA > ticket: https://issues.apache.org/

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

+1 On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh wrote: > Hello Dev list, > > I'd like to include a fix for GEODE-7763 in release 1.12.0. > The change removes the call to exportValue, preventing a serialization, > when no clients are waiting for the specific event. > The reason why I think it sho

[VOTE] Using Github issues and wiki for geode-kafka-connector project

Hello team, We are planning to experiment with using Github issues and wiki for the Apache project *Geode-Kafka-Connector. *(not Apache Geode project). Please do give your vote on this as we need to send the vote link to infra to activate it. *Why are we doing this ? / Advantages* : 1. *Unified l

[ANNOUNCE] Github Wiki and Issus are now activated on geode-kafka-connector

Hi, Issues are wiki pages are now active on the geode-kafka-connector repository. Thank you all for the kind votes. Regards Nabarun Nag

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

s a very robust project management tools used by Apache Contributors and corporations like VMware. Regards Nabarun Nag On Thu, Apr 23, 2020 at 2:40 PM Anthony Baker wrote: > Having used pretty every style of wiki, I care less about the wiki tech > and more about making the content easily a

Re: GitHub Project Board Applications API

It is just an experiment at the moment. We are researching ways of automating processes. It is an exploration attempt hence not being discussed at this point in time as we don't have all the information. Regards Naba On Fri, May 1, 2020 at 4:00 PM Michael Oleske wrote: > Hi Devs! > > I saw on

Re: GitHub Project Board Applications API

We can ignore this board as it is not part of the agreed-upon open-source process at the moment. Regards Naba On Fri, May 1, 2020 at 4:26 PM Nabarun Nag wrote: > It is just an experiment at the moment. We are researching ways of > automating processes. It is an exploration attempt hen

Re: GitHub Project Board Applications API

in the near future. Regards Naba On Fri, May 1, 2020 at 4:28 PM Michael Oleske wrote: > What are you hoping to learn from the exploration? What hypothesis is the > experiment trying to prove/disprove? > > -michael > > On Fri, May 1, 2020 at 4:26 PM Nabarun Nag wrote:

Re: Our May 2020 report to the board

Thank you Dave for putting together the report !! Thank you all for putting together those amazing blogs and all the Apache Geode contributors. Regards Naba Get Outlook for iOS From: Karen Miller Sent: Monday, May 11, 2020 2:30:35 PM To:

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

+1 On Thu, May 14, 2020 at 8:54 AM Donal Evans wrote: > Thanks for the explanation, Robert. Also, I realised I never explicitly > said it in my earlier post, but this is a +1 from me > > On Thu, May 14, 2020 at 8:05 AM Joris Melchior > wrote: > > > This seems like a good thing to have. > > > >

New blog on Spring Security & Geode by Juan Ramos

Hi Geode Community, Juan Ramos has recently published a new article on Spring Security and Apache Geode. You can read it here at https://medium.com/@jujoramos/spring-security-geode-4670faff47a0 Thank you Juan for this article. Regards Nabarun Nag

RE: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

- We are maintaining feature/GEODE-7665 which is the feature branch for PR clear work on which multiple developers are working on. - We are maintaining this in Geode repository. - All sub-tasks of GEODE-7665 are merged into this feature branch. - Anyone in the Geode community can work on any subt

RE: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

things you have specified are possible within the confines of a fork. Thanks, Mark On 6/2/20, 4:29 PM, "Nabarun Nag" wrote: - We are maintaining feature/GEODE-7665 which is the feature branch for PR clear work on which multiple developers are working on. - We are maintaining thi

RE: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

Jun 2, 2020, at 4:40 PM, Nabarun Nag wrote: > > I don’t think it is right to make the open source Geode Community to work on > my personal fork Why not? I can fork your fork. I can PR to your fork. Its sort of what Git was made for, no single source repository. Can you elaborate on

RE: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

@geode.apache.org Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches > On Jun 2, 2020, at 4:29 PM, Nabarun Nag wrote: > > - We are maintaining feature/GEODE-7665 which is the feature branch for PR > clear work on which multiple developers are working on.

RE: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

Thank you Aaron. We will continue using feature branch in ASF repo for development of PR clear work. Yes, we can manage access to personal/non-ASF hosted forks but I do not have the list of people to set that up. This is automatic default when we create in ASF repositories. Also, I am vehemen

Re: About Geode rolling downgrade

Hi Mario and Alberto, I will sync up with couple of engineers get you a feedback within a couple of days. @Barry , Jason and I were discussing once, can your idea of WAN GII achieve the downgrade. Like create a DS with old versions and let it do a GII from the newer version cluster and then s

RE: Setting your commit email address

Hi Kirk, I think it is also now in the privacy setting in GitHub for anyone who wants to keep emails private. [https://github.com/settings/emails : https://github.com/settings/emails ] This setting is needed for web based git operations like squash merging PRs etc. In GitHub: "Keep my email a

[VOTE] Backporting of GEODE-8261 to 1.13 release branch.

Hi Geode devs, Requesting vote to backport of GEODE-8261 to 1.13 Why? This commit fixes an issue with servers throwing null pointer exceptions while a member is being shutdown and registering interest is in process. SHA 720a4caea2ddb22296aa3225fc5264d2096cdf20 Regards Nabarun

RE: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

: [VOTE] Backporting of GEODE-8261 to 1.13 release branch. +1 On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag wrote: > Hi Geode devs, > > Requesting vote to backport of GEODE-8261 to 1.13 > > Why? > This commit fixes an issue with servers throwing null pointer > exceptions wh

Re: [PROPOSAL] backport GEODE-8394 to support/1.13

Super +1 From: Anilkumar Gingade Sent: Friday, August 7, 2020 10:34 AM To: dev@geode.apache.org Subject: [PROPOSAL] backport GEODE-8394 to support/1.13 This causes a large object to be partially (corrupt data) stored in cache instead of throwing an exception.

Re: Draft of August 2020 Geode report to the board

Hi Udo, I think the wrapped links appear only in outlook. In Apache archives, they appear to be medium links. Safelinks is feature enabled by default in Outlook Regards Naba Get Outlook for iOS From: Udo Kohlmeyer Sent: Sunday, August 9,

  1   2   3   4   >