Re: [VOTE] Apache Geode 1.15.1.RC1

Please ignore the above email. I wrote it a while ago, but my email client only decided to send it now From: Alexander Murmann Date: Tuesday, October 11, 2022 at 7:29 AM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.15.1.RC1 ⚠ External Email The RC is ready to go and the voting

Re: [VOTE] Apache Geode 1.15.1.RC1

The RC is ready to go and the voting deadline is almost a week in the past, but we aren’t hearing form Mario. It might make sense for someone else to finalize the release. Any objections and/or volunteers? From: Anthony Baker Date: Thursday, October 6, 2022 at 6:16 AM To: dev@geode.apache.org

Re: Apache Geode 1.15.1 patch version

Hi Mario and Weijie, How are things looking with the release. It seems like GEODE-10415 about the CVEs in dependencies is still open. Do you folks have any questions or need help with anything related to the release or the CVEs? From:

Re: Release manager for 1.15.1?

Hi Rupert and Anthony, Thanks for your initiative, Rupert! It’s great to see community members step up like this. Unfortunately, there isn’t much you can do to help with the release without being a committer or ideally a PMC member, since the vast majority of steps require committer

Re: CODEOWNERS? (was Re: Pending PR reviews)

+1 to removing CODEOWNERS. It was a good idea, but isn’t working well, in part due to the way GitHub doesn’t provide enough information to determine who is actually needed for review. From: Anthony Baker Date: Wednesday, June 29, 2022 at 9:34 AM To: dev@geode.apache.org Subject: CODEOWNERS?

Re: [Proposal] Make "Affects Version" field mandatory for new tickets with "Bug" issue type in JIRA

I think this is a great idea! I looked into this a while ago, but at the time couldn't find a way to make a field required only for a certain ticket type without additional, commercial extensions for JIRA. From: Donal Evans Sent: Thursday, May 26, 2022 10:09

Re: [PROPOSAL] RFC for migrating from springfox to springdoc

Thanks for your proposal, Patrick! I wonder if this even warrants a proposal over a PR. There seems to be neither a downside nor a realistic alternative. From: Patrick Johnson Sent: Thursday, May 5, 2022 13:39 To: dev@geode.apache.org Subject: [PROPOSAL] RFC

Re: [discuss] Future of the geode-redis module

, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action? From: Alexander Murmann Sent: Thursday, April 14, 2022 5:15 PM

[discuss] Future of the geode-redis module

Hi Geode community! A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands. VMware will not

Re: [DISCUSS] Testing and voting on release candidates

This is awesome! Now I am excited to try this on our next vote!  From: Dan Smith Sent: Friday, February 4, 2022 10:56 To: dev@geode.apache.org Subject: [DISCUSS] Testing and voting on release candidates Hi all, I'd like to suggest something that might make

Re: Geode Jira Access Request

What's your username, Steve? From: Steve Sienkowski Sent: Monday, January 31, 2022 14:00 To: dev@geode.apache.org Subject: Geode Jira Access Request Hi team, Could someone help me get the proper access to the Geode Jira so that I may be assigned tickets?

Re: Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

may only serve to create a false sense of security. Also to consider, having a large refactor on develop but not support/1.15 will increase backporting pain, as many cherry-picks will have merge conflicts that have to be manually "un-refactored". On 1/25/22, 5:09 PM, "Alexander

Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

Hi everyone, Last week we discussed to cut the 1.15 release branch. I would like to propose that we cut the branch from last week's SHA 8f7193c827ee3198ae374101221c02039c70a561. The following commit is a very large refactor. Nothing obvious seems wrong with that change, but given that we

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.8.RC1

+1 verified signatures started a small cluster and ran some basic operations, as well as Pulse -- Please provide anonymous feedback for me here. From: Donal Evans Sent: Thursday, January 13, 2022 09:04 To:

January Community Meeting

Happy new year everyone, Our community meeting is set to be tomorrow. However, we don't have a topic. Unless someone proposes a topic in the next few hours, we should cancel.

Re: [DISCUSS] proposal to pare down old-version testing

+1 Great compromise! Let's not forget about this whenever we change the protocol -- Please provide anonymous feedback for me here. From: Anilkumar Gingade Sent: Tuesday, January 4, 2022 07:09 To: dev@geode.apache.org

Re: [DISCUSS] Adding LTGM as gating PR checks

+1 to adding this. Given it has a low false-positive rate, only checks on code actually changed in the PR and runs quickly compared to some of our other steps that already happen for every PR, this seems like an easy decision. From: Robert Houghton Sent:

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1

+1 verified signatures verified passing pipeline started a small cluster and ran some operations and Pulse From: Owen Nichols Sent: Tuesday, December 14, 2021 18:19 To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1 Hello Geode

Re: Creating index failed

Hi Mario! I agree with you that the user wanted to index all the data in the region when using a partitioned region. But when the command is not successful, the cluster config is not updated. After the server restart, it will not have indexes as it is not stored in the cluster configuration.

Apache Geode Community Meeting

Hi everyone, Sorry, I didn't organize the December community meeting that should have taken place today. Given, it's the holiday season coming up, I wonder if it makes sense to not bother rescheduling and instead start looking at our January meeting. Does anyone have a topic they'd like to

Re: @TestOnly or @VisibleForTesting

Another +1 to Eric's point. What are others seeing as valid use cases for those annotations? From: Patrick Johnson Sent: Thursday, November 4, 2021 15:55 To: dev@geode.apache.org Subject: Re: @TestOnly or @VisibleForTesting I agree with Eric. Maybe rather than

Re: November Community Meeting

ng the topic. ____ From: Alexander Murmann Sent: Thursday, October 28, 2021 08:01 To: geode Subject: November Community Meeting Hi everyone, A week from now on Thursday November 4th at 15:00 UTC/8:00 Pacific is our next Geode Community Meeting. Currently the agenda is a talk on Qu

November Community Meeting

Hi everyone, A week from now on Thursday November 4th at 15:00 UTC/8:00 Pacific is our next Geode Community Meeting. Currently the agenda is a talk on Query Resource Management. Please find all details on the corresponging wiki

Re: Apache Geode Community Meeting 10/7/2021

Hi Jake, Sorry to hear about your family emergency. It's probably too short notice to prepare another topic and to allow everyone interested to get ready for discussion as well. Pushing back to next Thursday, October 14th is probably our best bet. All the best to you and your family!

Re: October Community Meeting

nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FKToH0m75SbWG%2BWHFVXPEknTMBGuO%2BT7jISatzhBgjQ%3Dreserved=0 On Sep 29, 2021, at 9:09 AM, Alexander Murmann mailto:amurm...@vmware.com>> wrote: Hi everyone! Next Thursday October 6th is our next Community Meeting. J

Re: October Community Meeting

Sorry, this is of course Thursday, October 7th. From: Alexander Murmann Sent: Wednesday, September 29, 2021 09:09 To: geode Subject: October Community Meeting Hi everyone! Next Thursday October 6th is our next Community Meeting. Jacob Barrett has started some

October Community Meeting

Hi everyone! Next Thursday October 6th is our next Community Meeting. Jacob Barrett has started some discussions on the mailing list about modularization. This is a great topic for our upcoming meeting. Jake won't be able to join till one hour after our regular time. I hope everyone is fine if

Re: August Community Meeting

on ClassLoader isolation that he and Udo Kohlmeyer have been doing. Sorry for the short notice! -- Please provide anonymous feedback for me here<https://forms.gle/kpUiaty3jt8X9y4H9>. From: Alexander Murmann Sent: Tuesday, August 3, 2021 10:06 To: geode Subje

Re: August Community Meeting

e wiki if you have something you'd like to discuss. See you all next week! From: Alexander Murmann Sent: Thursday, July 29, 2021 11:00 To: geode Subject: August Community Meeting Hi Geode community, Next week's August 4th is the first Wednesday in August. U

August Community Meeting

Hi Geode community, Next week's August 4th is the first Wednesday in August. Usually that would be the day that we have our community meeting. Many of our community members work on Apache Geode as part of their work at VMware. The majority of those folks will be unavailable next week. Does it

Re: July Community Meeting

We still have not topics for tomorrow. Let's skip this month. See you all in August! From: Alexander Murmann Sent: Friday, July 2, 2021 16:02 To: geode Subject: July Community Meeting Hi, my favorite caching community! Just a reminder that next Wednesday, July

July Community Meeting

Hi, my favorite caching community! Just a reminder that next Wednesday, July 7th is our next community meeting. So far, we have no proposed topics. Please try to add your topics ahead of time. I suggest

Re: June Community Meeting

317008d9243d7bb7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637580668760838009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=apgD8MLWngDBxbId0%2FkK9yPijaj%2BamjCc%2BdclLA58DM%3Dreserved=0 Best regards, Alberto ____ From: Alexander Murmann

Re: [Discuss] New feature work approval state in Geode project?

I've also seen this on other projects where sometimes an issue gets substantial support, but ultimately gets rejected because it doesn't match the project's direction. Making this clear before work happens makes sense to me in general. However, I wonder if the additional process in our case is

June Community Meeting

Hi everyone, Next Wednesday, June 2nd, it's time for our next Geode Community Meeting. So far, our only agenda item is "geode retry/acknowledge improvement" presented by contributors from the team at Ericsson. If you have anything you'd like to present or discuss, please add it to our agenda

Re: Today's Community Meeting

Sorry, our next meeting won't be April 2nd, but June 2nd. Apparently, I've lost all sense of time during the pandemic. From: Alexander Murmann Sent: Wednesday, May 5, 2021 09:39 To: geode Subject: Today's Community Meeting Hi everyone! It was great to see so

Today's Community Meeting

Hi everyone! It was great to see so many folks attend our first community meeting today and contribute to the discussion. An especially big thank you goes to Alberto Gomez for presenting his

Re: [DISCUSS] Monthly, synchronous community meetings

will have to figure out what topics work well for this format, and which don't. The best way to do that is to just try and learn together in public. Looking forward to seeing you all! ____ From: Alexander Murmann Sent: Monday, April 19, 2021 11:58 To: dev@geode.apache.or

Re: [DISCUSS] Monthly, synchronous community meetings

, synchronous community meetings Hi, This idea sounds great to me. Have you thought about the videoconference platform to host these meetings? Best regards, Alberto From: Alexander Murmann Sent: Friday, April 9, 2021 2:46 AM To: dev@geode.apache.org Subject: [DISCUSS

[DISCUSS] Monthly, synchronous community meetings

Hi everyone, On occasion we see discussions on PRs, here on the mailing list that might be move much quicker if we chatted synchronously about some of these topics and then shared the meetings notes back to the mailing list. Of course, our usual processes for voting and additional discussions

Re: request for people putting up pull requests

Thanks for calling this out, Bruce! Even ignoring the curtesy to reviewers, it's hugely beneficial to have at least descriptive commit messages, that describe the intent behind the change and maybe even give a little bit of insight into the design decision. JIRA is great, but all our IDEs and

Re: [VOTE] Apache Geode 1.13.2.RC1

unwise. From: Alexander Murmann Sent: Monday, March 22, 2021 1:59 PM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.13.2.RC1 Sorry, everyone! We still haven't gotten to the bottom of the very slow registerInterest. More details should be coming in a ticket as we get

Re: [DISCUSS] removal of experimental Protobuf client/server interface

Udo, having worked on Protobuf with you, I share the emotional attachment. I also agree that it's a valuable feature to have and that ideally someone would pick it up. I don't think it's feature complete enough at this point to be viable. Unlike with Redis, I haven't seen anyone in the

Re: [DISCUSS] removal of experimental Protobuf client/server interface

+1 for removal From: Mark Hanson Sent: Tuesday, March 23, 2021 11:44 To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface +1 for removal. On 3/23/21, 8:46 AM, "Darrel Schneider" wrote: I'm in favor of

Re: [VOTE] Apache Geode 1.13.2.RC1

, 2021 -Original Message- From: Alexander Murmann Sent: Thursday, March 18, 2021 1:23 PM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.13.2.RC1 I am sorry, can we get another 24 hours to analyze the long registerInterest calls, please? Thank you

Re: [VOTE] Apache Geode 1.13.2.RC1

1.13.2.RC1 voting deadline is now: 3PM PST Thurs, March 18, 2021 -Original Message- From: Alexander Murmann Sent: Tuesday, March 16, 2021 1:46 PM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.13.2.RC1 Can we please extend the vote for another 48 hours? We are investigating

Re: [Proposal] Backport GEODE-9045 to support/1.14

Seems like a no-brainer given the very low risk in the change and that it comes with legal reasons From: Hale Bales Sent: Wednesday, March 17, 2021 11:42 To: dev@geode.apache.org Subject: [Proposal] Backport GEODE-9045 to support/1.14 Hello, I am putting

Re: [VOTE] Apache Geode 1.13.2.RC1

Can we please extend the vote for another 48 hours? We are investigating a potential issue in which registerInterest is taking over 5 minutes. It's still unclear what exactly is causing that, but some more time to investigate would be better than potentially shipping a bug like this.

[DISCUSS] Cutting a Geode 1.14.0 release branch

Hi everyone, We aren't seeing many issues that would prevent a 1.14.0 release on our blocker board and all issues have an owner. No new issues seem to be coming in either. This seems like a good time to finally cut a

Re: [DISCUSS] Geode 1.14

. From: Alexander Murmann Sent: Tuesday, January 5, 2021 08:34 To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 I agree with Jianxia that a dashboard would be helpful. Not every bug that affects a release should necessarily be a release blocker. Factors like low severity

Re: [DISCUSS] Geode 1.14

I agree with Jianxia that a dashboard would be helpful. Not every bug that affects a release should necessarily be a release blocker. Factors like low severity, existence in prior versions and time to fix might all play a role in deciding that a bug should be fixed in a later version. So we

Re: [DISCUSS] Geode 1.14

e original quarterly cadence: Feb 1 2021. -Owen From: Alexander Murmann Date: Tuesday, July 28, 2020 at 4:34 PM To: dev@geode.apache.org Subject: [PROPOSAL] Postpone Geode 1.14 Hi all, As mentioned on the previous discuss thread, I propose to hold off cutting 1.1

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

+1 I agree with Owen's point that this will improve the experience for new contributors. It also helps people new to the community to have confidence that they got the type of review they need to feel confident to merge. I might get to reviews that are both from great committers who can review

Re: PR process and etiquette

Let's try to move this towards action: It seems like we have consensus that a CONTRIBUTING.md file is a great idea. We also have consensus to recommend in there that one should be mindful to create PRs as drafts if you don't consider them ready for review. It seems reasonable that one might

Re: How to add a new REST end point in Cluster Management Service

lated docs into different places though. Any feedback is welcome. On 11/10/20, 1:54 PM, "Alexander Murmann" wrote: Jinmei, I am still not sure I understand if this is a proposal. It's listed under proposals but written more like a how-to. So given the feature is still in p

Re: [PROPOSAL] Backport GEODE-8536 and GEODE-8686 to 1.13.1

+1 Thanks for fixing those, Donal! From: Donal Evans Sent: Tuesday, November 10, 2020 15:46 To: dev@geode.apache.org Subject: [PROPOSAL] Backport GEODE-8536 and GEODE-8686 to 1.13.1 Hi Geode dev, I would like to backport the fixes for the below issues to the

Re: How to add a new REST end point in Cluster Management Service

? From: Jinmei Liao Sent: Tuesday, November 10, 2020 10:06 To: dev@geode.apache.org Subject: Re: How to add a new REST end point in Cluster Management Service It's a feature still in development. Should we move the entire CMS specs to another section? On 11/6/20, 3:32 PM, "Alex

Re: How to add a new REST end point in Cluster Management Service

Jinmei, thanks for writing this! Can you help me understand why this is listed under Project Proposals and Specifications? From: John Blum Sent: Wednesday, October 28, 2020 08:27 To: dev@geode.apache.org Subject: Re: How to add a new REST end point in Cluster

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

Oh, I am so sorry Mario! I mistakenly was under the impression the change was related to more failures. I should have looked more carefully! Thank you for the fix! ?? From: Mario Ivanac Sent: Friday, October 23, 2020 13:39 To: Alexander Murmann ; dev

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

y hide very real bugs. That's why earlier this year several people spent a few months improving the reliability of our tests. Mario, in July you said you were investigating this. Is that still ongoing? Do you need any help? From: Alexander Murmann Sent: Tuesday

Re: [DISCUSS] Shipping patch releases

I would feel much more comfortable if the default behavior was to always port back in reverse order without skipping a support branch. This makes it much harder to forget poring to a support branch. Few things are more frustrating to users than upgrading to a new patch release to get a bug fix and

Re: Proposal to bring GEODE-8456 (shiro upgrade) to support branches

+1 On Tue, Sep 1, 2020 at 6:19 AM Sarah Abbey wrote: > +1 > > From: Ju@N > Sent: Tuesday, September 1, 2020 4:10 AM > To: dev@geode.apache.org > Subject: Re: Proposal to bring GEODE-8456 (shiro upgrade) to support > branches > > +1 > > On Tue, 1 Sep 2020 at

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

+1 On Mon, Aug 3, 2020 at 4:47 PM Jianxia Chen wrote: > +1 > > On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider wrote: > > > GEODE-6564 is a memory leak that has impacted users so it would be good > to > > have it in 1.13. It has a simple, low risk, fix. > > >

Re: [PROPOSAL] Postpone Geode 1.14

enough once decided? > > --Mark > > On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior > wrote: > > > +1 > > > > On 2020-07-28, 7:34 PM, "Alexander Murmann" > wrote: > > > > Hi all, > > > > As mentioned on the previous

[PROPOSAL] Postpone Geode 1.14

Hi all, As mentioned on the previous discuss thread, I propose to hold off cutting 1.14 until we have shipped 1.13. Once we have shipped 1.13, we should discuss when we want to cut the 1.14 release. The actual ship date for Geode 1.13 is important information for that conversation. Thus we

Re: [Discuss] Cutting Geode 1.14

> the non-stop process of finding and fixing bugs in the release, > since 1.14 > > will have all of the same blockers that 1.13 currently has, plus an > > undetermined number of additional ones that we may not know about > yet. > > >

Re: [Discuss] Cutting Geode 1.14

_ > From: Jacob Barrett > Sent: Monday, July 20, 2020 9:38 AM > To: dev@geode.apache.org > Subject: Re: [Discuss] Cutting Geode 1.14 > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > On Jul 20, 2020, at

Re: [Discuss] Cutting Geode 1.14

dev@geode.apache.org > Subject: Re: [Discuss] Cutting Geode 1.14 > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > On Jul 20, 2020, at 9:21 AM, Alexander Murmann > wrote: > > > > Hi everyone, > > > > TL;DR: Let's discuss 1.14 once 1.13 is

[Discuss] Cutting Geode 1.14

Hi everyone, TL;DR: Let's discuss 1.14 once 1.13 is out. If we stick to our cadence of cutting a release every 3 months and shipping it 1 month later, 1.14 is due to be cut two weeks from today. However, we haven't shipped 1.13 yet and are still struggling with some issues. I suggest that we

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

lowing troubleshooting. > > BR, > Mario > ________ > Šalje: Alexander Murmann > Poslano: 14. srpnja 2020. 1:11 > Prima: Alexander Murmann > Kopija: dev@geode.apache.org ; Mario Ivanac > > Predmet: Re: [INFO] Latest test run of 200 DistributedTestO

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

to get our code committed with confidence. Can we resolve this issue? Otherwise, I think we need to consider reverting GEODE-7458. On Fri, Jun 19, 2020 at 3:28 PM Alexander Murmann wrote: > Looking more into this, it looks like this was introduced by the changes > for GEODE-7458 - "

Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13

While it's really late in the branch lifecycle and we should have shipped a month ago, performance degradations are a no-go +! On Thu, Jul 9, 2020 at 8:00 AM Bruce Schuchardt wrote: > There are reports that SSL performance is off on the support/1.13 branch > with respect to the support/1.12

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

Hi Alberto, The timing on this RFC feels really tight. Would you be open to extending this to next week? On Wed, Jul 8, 2020 at 1:04 PM Eric Shu wrote: > I think the only case the memory issue occurred is when all gateway > senders are stopped in the wan-site. Otherwise another member would

Our Slack channel

Hi community, For some of our coordination efforts, like release status updates, coordination of flaky tests or collective debugging of some issues a more synchronous medium might be useful. We've had an Apache Geode Slack channel for a long time, but never used it much. I wonder if it would be

This week's mass-test run results

Hi everyone, Just like Mark did two weeks ago, I'd like to bring some attention to our mass test runs. These now run in the pipeline once a week. The results should typically be available on Tuesdays.

Re: Fate of master branch

+1 to deleting. Given we tag everything properly on the other branches, I don't see the need for it either. On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes wrote: > +1 for deleting master branch. An also for updating the wiki page about > branching that Alberto pointed out. >

Re: JIRA access

Hi Louis, You should have access now Please let me know if you need any further help On Mon, Jun 22, 2020 at 10:33 AM Louis Jacome wrote: > Hello, > > I am emailing to request access to the Geode project, I have a personal > account registered under louisjac...@gmail.com that I would like

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

reverting the change? Thank you! On Fri, Jun 19, 2020 at 7:57 AM Alexander Murmann wrote: > Thank you so much for sharing this, Mark! > > It looks like there is a big cluster around WAN Gateway. Is anyone already > looking into the WAN issues? > > On Thu, Jun 18, 2020 at

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

Thank you so much for sharing this, Mark! It looks like there is a big cluster around WAN Gateway. Is anyone already looking into the WAN issues? On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson wrote: > FYI, the build success rate was around 90% or so about two months ago. > > Here are the DUnit

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

+1 to avoiding clutter by not using feature branches on the Geode repo. Sharing your own repo, as Kirk suggests, also works better when collaborating with folks who aren't committers. On Tue, Jun 2, 2020 at 4:16 PM Kirk Lund wrote: > I prefer to share a fork among multiple developers instead

Re: [DISCUSS] Adding Google Analytics to our website

anaged > by the PMC. > > Anthony > > > > On May 4, 2020, at 11:57 AM, Alexander Murmann > wrote: > > > > Seems like nobody has objections to adding this. > > > > Google Analytics requires a Google account. Does is work if I create this &g

Re: [DISCUSS] Adding Google Analytics to our website

ng > > at RabbitMQ (rabbitmq.com), which uses their platform to host tutorials, > > best practices, and other content. I could find $$$ in my budget to help > > modernize the Geode site and make it more generally useful as a content > > platform for developers and others in

Re: [DISCUSS] Adding Google Analytics to our website

What things are we looking to learn? Without knowing what we are > interested in learning I would be hesitant to add anything. If we know > what we want to learn then a conversation about analytics would be more > fruitful (to me at least) > > -michael > > > On Tue, Apr

[DISCUSS] Adding Google Analytics to our website

Hi all, In promoting our project it might be valuable to get a better idea of where visitors on our website come from, what they look for and where we lose them. This should help us improve the website and learn what kind of blogs articles, videos etc. drive user interest to the website. To gain

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

I am not sure I am following the argument for removal in a minor version. Let's expand the argument and make sure we are all basing this on the same assumptions: Java has removed insecure encryption algorithms in patch releases. This was presumably done because it's really fixing a vulnerability,

Re: PR Titles

> > Don't we have a published checklist or guideline or something for this > already? Including stuff like 'always prefix the PR title with a JIRA > ticket #,' etc? Yes, we do. However, it only request the addition of the JIRA ticket #. It does not call out having a descriptive title. I like

Re: [DISCUSS] RFC: Shipping Geode patch releases

uot;predictable" > intervals (e.g. every 6 weeks), not on an adhoc basis. > > $0.02 > -John > > > On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann > wrote: > > > > > > > Or, we could emphasize the shift in process with bigger changes: > > >

Re: [DISCUSS] RFC: Shipping Geode patch releases

w > will committers be able to keep track of what is dormant and what is not?) > >> > > > > Why not just either a) keep the release branch alive? Or b) create a > support branch from the release tag? > > > >> To implement an N-2 support policy, does it

Re: [DISCUSS] RFC: Shipping Geode patch releases

Thanks for proposing this, Anthony! > I don’t think it’s necessary for this proposal to re-define or clarify > what constitutes a critical fix; it sounds like the bar would be the same > as the standard we already apply when back-porting to release branches > (proposal /w justification, and 3

Re: [Vote] Include GEODE-7752 into 1.12

fy and make this process > > more intuitive for users. > > > > Does this answer your question as to why? > > > > --Udo > > > > > > On 2/5/20 3:01 PM, Alexander Murmann wrote: > > > Udo, you say "refactor", but this sounds more like a

Re: [Vote] Include GEODE-7752 into 1.12

Udo, you say "refactor", but this sounds more like a feature or user facing improvement. Do you mind elaborating a little more why this should be in this release? On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson wrote: > +1 > > On 2/5/20, 1:53 PM, "Udo Kohlmeyer" wrote: > > Hi there Geode

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

+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 change is basically to avoid throwing an exception and return the > > correct result

Re: Old geode-benchmark PRs

Donal, are you still looking at these? If they aren't ready to merge and not being worked on, should they be closed? On Wed, Jan 22, 2020 at 3:32 PM Donal Evans wrote: > Two of those PRs are mine, so perhaps I can give a bit of context for > people who might look at them. The oldest of the two,

Re: Requesting permission to upload Apache Geode to Docker Hub

You should have access now. Thanks for stepping up as release manager! On Fri, Jan 17, 2020 at 11:16 AM Ernest Burghardt wrote: > 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

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

Here are a few things that are true for me or I believe are true in general: - Our test suite is more flaky than we'd like it to be - I don't believe that adding more Unit tests that follow existing patterns buys us that much. I'd rather see something similar to what some folks are

Re: [REQUEST] Squash merge please

I wonder if Kirk's and Naba's statements are necessarily at odds. Make the change easy (warning: this may be hard), then make the easy > change." -Kent Beck Following Kent Beck's advise might reasonably split into two commits. One refactor commit and a separate commit that introduces the

Re: New geode-gfsh module

> I imagine once the Management v2 API's are GA (and feature complete), I don't see a reason why /gfsh/ should not be a stand alone module. It would definitely have to be updated to use the new v2 API's, which should not have any direct dependency on geode-core any more. There also is a big

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

Joris, the "to be reviewed by" field is for a target date by which to wrap up the discussion. Do you mind updating the field and letting the mailing list know what timeframe you envision? Thanks! On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior wrote: > Hi All, > > Looking for feedback on the

Re: [DISCUSS/VOTE] Proposal to bring GEODE-7465 to release/1.11.0

+1 On Tue, Nov 26, 2019 at 11:32 AM Udo Kohlmeyer wrote: > This is no-brainer > > *+1* > > On 11/26/19 11:27 AM, Owen Nichols wrote: > > I would like to propose bringing “GEODE-7465: Set eventProcessor to null > in serial AEQ when it is stopped” into the 1.11 release (necessitating an > RC4). >

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

+1 If we get to 200, the refactor implements itself, right? On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh wrote: > +1 > I think we are now at +114 thanks to jinmei's 100 ;-) > > > On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl wrote: > > > +1 > > > > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag

  1   2   3   >