Re: Default branch for geode-examples

I agree that there is a conflict here of what might be most usable for users vs. developers contributing to the geode-examples repo. No matter which route we go down, we should improve guidance. If we keep master the default, I +1 Owen's suggestion of amending the template. If we make develop the

[ANNOUNCE] Apache Geode 1.8.0

possible. Regards, Alexander Murmann on behalf of the Apache Geode team

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

Thank you for catching this Brian! I will take a look and see how we can address this. On Thu, Dec 20, 2018 at 3:21 PM Brian Rowe wrote: > The maven repository for 1.8.0 seems to be missing the 1.8.0 source jars. > This means people using an IDE can't download these jars automatically to > see t

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

I confirmed what we upload to the Nexus staging site again with both 1.7 and 1.8. I think we must have stopped uploading these files when we switched to the maven-publish plugin as part of GEODE-5597. Can someone who worked on the recent build changes please take a look? I created GEODE-6235 to tr

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

response. If we can put the > missing jars in place manually for 1.8.0 that should be sufficient. > > -Owen > > > On Dec 21, 2018, at 9:16 AM, Alexander Murmann > wrote: > > > > I confirmed what we upload to the Nexus staging site again with both 1.7 > >

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

he new plugin. > >> > > >> > > >> > Anthony > >> > > >> > [1] > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gradle.org_current_userguide_publishing-5Fmaven.html&d=DwIFaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJu

Re: [Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

Ryan, thank you so much for the great explanation of your proposal! This seems very sound and you and David got me convinced that it's the right thing to change the default. To me the question now is one of timing. Is this something we can change in a minor release or do we have to wait for Geode

Re: [Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

since it is a behavior change and apparently there are > several > >> config parameters for which we'd like to change the default, but we > pushed > >> it to 2.0. I don't feel super strongly either way. Do you want to > reply > >> to this thread or ta

Geode 1.9 Release Manager

Hi everyone! February 1st is approaching rapidly which means it's almost time to cut the 1.9 release. Who is interested in being the release manager for 1.9? Thank you!

Very red CI -> Hold merges, please

Hi folks, Our CI is very red since ~24 hours . It looks like a substantial new issue was introduced. Can we hold off on merging new changes to the develop branch till this issue is re

Re: Very red CI -> Hold merges, please

eb 7, 2019 at 9:57 AM Nabarun Nag > wrote: > > > > > > > > > >> 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. > >

Re: Very red CI -> Hold merges, please

> > > GfshConsoleModeUnitTest UnitTest failures. > >> > > > > > >> > > > > On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag > >> wrote: > >> > > > > > >> >

Re: Geode 1.9 Release Manager

If there are no other takers, I can act as release manager for 1.9 and will cut a release branch this week. On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann wrote: > Hi everyone! > > February 1st is approaching rapidly which means it's almost time to cut > the 1.9 release.

Re: Geode 1.9 Release Manager

new issues being introduced? Thoughts? Thank you, Sai for taking over! On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda wrote: > I volunteer to be the release manager for 1.9. > > Sai > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann > wrote: > > > If there are

Re: Geode 1.9 Release Manager

t; > Regards > Naba > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Did we not agreed that we won't be blocking a release to include fixes as > > we are in a fixed release schedule? > > > >

Re: Geode 1.9 Release Manager

xes means that we are releasing with > serious known issues in the product. Hence in my opinion this risk is > acceptable. > > Regards > Naba > > On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann > wrote: > > > > > > > For the second part, I am not sure

Re: Release branch for Apache Geode 1.9.0 has been cut

> > Oh ok I thought I read that voting was going to start soon > Are you referring to the RC vote? Per the previous discussed release schedule and the wiki , the actual release shouldn't happen till March 1st. On Wed, Feb 20, 2019

Re: Bug Numbers and Trac Numbers in comments

I think it's important that we enable everyone in the community to be equally successful and on top of that do NOT rely on non-Apache resources. If we find value in Trac numbers, we should either find a way to make them accessible to everyone or update the comment so that there is no value in knowi

1.9 release date

Hi everyone, According to our wiki we were aiming for a March 1st release date for our 1.9 release. We cut the release branch about two weeks late and see unusual amounts of merges still going into the branch. I propose that we give ourselves some more time to validate what's there. My proposal is

Re: 1.9 release date

orried about > when the release will be done (because uncertainty) and more focused on > ensuring we have demonstrated stability on the release branch. Hopefully > that will happen sooner than 4/1…but it could take longer too. > > > > Anthony > > > > > >> On Fe

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

+1. We want to ship with confidence and we have more trust in develop right now. On Tue, Mar 19, 2019 at 2:11 PM Dick Cavender wrote: > +1 to re-cutting the 1.9 release branch off a more stable develop sha > within the last couple days. > > On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt > wro

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

Dale, do I understand correctly that the only concern around the Micrometer work right now it that it's not useful yet, however it's not harmful either? Dave, is it correct that if that PR doesn't make it into the newly cut branch, we'd be shipping with a older version of geode-native? What are th

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

; The geode-native PR will be ready to check in momentarily. Just waiting > > for Travis to do its diligence. > > > > On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann > > wrote: > > > >> Dale, do I understand correctly that the only concern around the > &

Re: [DISCUSS] Move or remove org.apache.geode.admin

The way I interpret https://semver.org/, deprecated functionality should be removed in a major release. Users should be able to update to a new minor release without having to worry that any of their code will break. It's certainly more convenient for us to mark as deprecated and then remove whene

Re: [DISCUSS] Move or remove org.apache.geode.admin

Would we announce that we aren't following semver anymore because bumping the major version is somehow too expensive? On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund wrote: > 1) +1 YES. If we continue to *not* have at least one major release per > year, then I 100% support the removal of deprecated API

Test coverage and PRs

Hi everyone, TL;DR: 1. Let's call each other out on our PRs when test coverage is missing or insufficient 2. Let's require test coverage for code that gets refactored as well We already have a really great wiki page

Re: [DISCUSS] require reviews before merging a PR

+1 to Jake's interpretation of the voting system not having been adjusted yet for the new world that is GitHub. When I read the Apache voting guidelines they make sense to me for bug decisions but not for a regular PR. The inertia coming with three votes on every PR is way more costly than the alt

Re: [DISCUSS] require reviews before merging a PR

Jake, Owen is quoting the "VOTES ON CODE MODIFICATION" section from https://www.apache.org/foundation/voting.html . "code modification" == "every PR" is a interpretation that I think would bring the project to a grinding halt. On Fri, May 31, 2019 at 9:01 AM Jacob Barrett wrote: > > > > On May 3

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

+1 to updating the checklist. About single vs multiple commits: I think either is fine as long as it is deliberate and makes it easier to understand what someone is doing. If there is a large refactor that enables a small change, it is often easier to understand when these changes are in separate

Re: [DISCUSS] require reviews before merging a PR

Udo, I agree with many of the pains you are addressing, but am pessimistic that having more reviewers will solve them. You are absolutely correct in calling out that the code is ugly complex and missing coverage. The best way to address this is to clean up the code and improve coverage. You say yo

Re: [DISCUSS] require reviews before merging a PR

committers, as I am one. But I also know that I > mistakes are made regardless of intent. If we trust committers, why > review at all? Just commit... and we might catch a problem, we might not. > > --Udo > > On 6/5/19 11:20, Alexander Murmann wrote: > > Udo, I agree w

[DISCUSS] RFC 0: Lightweight RFC Process

Hi everyone, I am proposing a new process that is aimed to address some of the issues we've recently encountered in making collective decisions. The process I am proposing would use pull request to discuss proposals. To demonstrate the process, I submitted my proposal as a pull request

Re: [DISCUSS] RFC 0: Lightweight RFC Process

. Please take a look there <https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process> and let's discuss here if any changes should be made. Otherwise I intent to move the proposal to `active` tomorrow. Thank you everyone! On Thu, Jun 13, 2019 at 4:26 PM Alexander Mur

Re: [DISCUSS] Adoption of a Coding Standard

Hi Kirk, I think having a coding standard that goes beyond a formatting style guide is a great idea. There are many interesting things in the SEI CERT standard. However, it's also massive. I see 13 rules just about methods. Yet some guidelines that would be most important to me like limiting metho

Re: [DISCUSS] Adoption of a Coding Standard

ntry in the Coding Standard's Rules section that you feel is > irrelevant or incorrect? Please pick an example with a link to it so we can > discuss it. > > PS: There aren't any other Coding Standards that I would personally write > or recommend. > > On Mon, J

Re: [DISCUSS] RFC 0: Lightweight RFC Process

se states - is the proposal actively > under development? It might be nice to clearly distinguish between > proposals that are under development vs. finished. > > -Dan > > On Mon, Jun 24, 2019 at 2:31 PM Alexander Murmann > wrote: > >> Having the RFC discussion in a

Re: [DISCUSS] RFC 0: Lightweight RFC Process

Given discussion here and previous discussion on the PR, I consider this proposal approved and updated its state accordingly. I also incorporated Dan's suggestion of moving deprecated proposals and added a reference to the new process at the top of the Project Proposals and Specifications page

Re: [DISCUSS] RFC 0: Lightweight RFC Process

." If you know what state these > > proposals are in, please move them! > > > > > https://cwiki.apache.org/confluence/display/GEODE/Project+Proposals+and+Specifications > > > > On Wed, Jun 26, 2019 at 11:20 AM Alexander Murmann > > wrote: > > >

[DISCUSS] Time to cut Geode 1.10.0?

Hi everyone! We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of last year we discussed releasing quarterly. In the past we've had about a month between cutting a release branch and actually shipping our new minor. This means we are already behind our target release cadence.

Re: [DISCUSS] Time to cut Geode 1.10.0?

use a geode property to turn it > on/off. I would say we are ready to cut the geode 1.10.0 after that work is > complete. > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > wrote: > > > Hi everyone! > > > > We released Geode 1.9.0 on April 25th. That's a

Re: [DISCUSS] Time to cut Geode 1.10.0?

r that work > is > > complete. > > > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > > wrote: > > > >> Hi everyone! > >> > >> We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of > >> last yea

Re: [DISCUSS] Time to cut Geode 1.10.0?

t process of feature proposal. > > > > All work under the experimental cluster management service has not yet > > been approved by the agreed upon RFC process. > > > > I don't believe we should be including this work, experimental or > > otherwise. >

Re: [DISCUSS] Time to cut Geode 1.10.0?

t; > > some of the ground work to have been discussed, API's validated BEFORE > > > it is released into the wild. I mean this is a PUBLIC API, so we'd > > > prefer to get it more correct than the previous one. > > > > > > Maybe it is just me, taking

Re: [DISCUSS] Time to cut Geode 1.10.0?

the next release... > > EB > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann > wrote: > > > *Cutting the release* > > Do we have any volunteers to take over the release manager role? > > > > *Re: Udo's concerns* > > While I believe that iteratio

Re: [DISCUSS] Time to cut Geode 1.10.0?

other issues, we'd want to make sure get > > addressed > > > before we ship? > > > > > > On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt < > eburgha...@pivotal.io> > > > wrote: > > > > > > > There is a PR #3844 <https:

Re: [DISCUSS] Time to cut Geode 1.10.0?

e branchpoint > > (coming near the end of a nice period of solid green in the pipeline), > and > > I acknowledge that fair warning was given a week ago that a branch was > > “coming soon”, but I wonder if there is anything we can do to make the > > rules for what gets in a r

Re: Proposal to Include GEODE-7079 in 1.10.0

+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, > > Even if it is an existing issue I'd still consider it critical for those > c

Re: I propose including the fix for GEODE-3780 in 1.10

+1 it's a regression in 1.10 and a serious problem. On Mon, Aug 19, 2019 at 7:38 AM Bruce Schuchardt wrote: > It sounds like Udo is okay with this now. Any other concerns? > > On 8/17/19 2:07 AM, Owen Nichols wrote: > > On Aug 15, 2019, at 2:09 PM, Bruce Schuchardt > wrote: > > > > This is a f

Re: [DISCUSS] what region types to support in the new management rest api

Hey folks, I want to make sure that any other's product's roadmaps have no impact on any decisions we make about Apache Geode. Thanks! On Tue, Aug 20, 2019 at 10:45 AM Darrel Schneider wrote: > Is "group" support on the PCC roadmap or is the plan for the members of a > cluster to always be unif

Re: Propose including GEODE-7085 in 1.10

+1 While it's not new, it's critical On Mon, Aug 26, 2019 at 10:38 AM Juan José Ramos wrote: > +1 > > On Mon, Aug 26, 2019 at 6:36 PM Dan Smith wrote: > > > Hi, > > > > I'd like to propose including the fixes for GEODE-7085 into 1.10 (SHA's > > below). This is not a new issue, but it does resu

Re: dockerhub mojo

Dick, you should have access now. On Thu, Sep 26, 2019 at 9:38 AM Dick Cavender wrote: > Can someone with the ability give my docker hub account (docdixie) > permissions to upload the new geode 1.10.0 docker image? > > Thanks! >

Re: [DISCUSS] Blocking merge button in PR

Hi Naba, I recall that we last time decided against blocking it because we agreed that the test suite was too flaky at the time. It's my understanding that it has only gotten more flaky. I hope we can see an effort soon to remediate that and at that point revisit the topic. I don't have a strong

Re: Time to starting thinking about cutting the 1.11 release branch?

Hi Owen, Thanks for bringing this up! Given our track record, instability we have seen in the pipeline recently and that the holidays are coming up, I wonder if it makes sense to give the release more time to stabilize and cut the branch even earlier. Maybe we could try to find a release manager

Re: [DISCUSS] Blocking merge button in PR

+1 for the 👶 steps proposal On Fri, Oct 18, 2019 at 3:30 PM Donal Evans wrote: > Big +1 from me on the revised proposal. It seems like there'd rarely be > a case where something needs to be merged so fast that we can't even wait > for the build and unit tests to pass, and preventing the addition

Re: [DISCUSS] Blocking merge button in PR

Udo, I think you are making a great point! I am fully bought into trusting our committers to know how many reviews are needed for their PRs. We should be able to have the same trust into knowing when it's OK to merge. If a committer wants to they can after all, always merge and push without a PR. T

Re: Time to starting thinking about cutting the 1.11 release branch?

date to plan around! > > > > As much as I would love to volunteer again, this would be a really > fantastic opportunity for a new committer who hasn’t done a release > before. Don’t be shy! No prior experience required! > > > > -Owen > > > >> On

Re: [VOTE] Apache Geode 1.9.2.RC1

+1 Downloaded source code, build and ran tests. Started a cluster and was able to execute basic operations. Compiled and ran examples Validated pipeline was run successfully for the SHA we are shipping On Tue, Oct 22, 2019 at 2:17 AM Ju@N wrote: > +1, > > Downloaded and built from source, creat

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

Owen, could you remind me which step requires PMC creds? I don't recall needing them when I managed a release earlier this year. On Mon, Oct 28, 2019 at 2:10 PM Owen Nichols wrote: > Fantastic, Mark! > > Please having a look at > https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache

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

👍🏻 This matches what we discussed on the previous thread! Thanks of stepping up! On Mon, Oct 28, 2019 at 2:33 PM Mark Hanson wrote: > Hi All, > > Looks like I won the contest to be release manager by default, so let's > get started…. > > I think we should cut the branch on November 4th, 2019.

Re: Release candidate target date...

I think it's really great to agree on the date by which we want to have a RC1 early. However, I thought the target release date is beginning of December, which would probably bring us to December 2nd, given the first is a Sunday. The voting period is 3 days. I would have expected that we'd create t

Re: Release candidate target date...

t takes > more than one RC? > > * some people might prefer to give feedback against a formal RC rather > than informally against the branch? > > * impact of Thanksgiving? > > > >> On Nov 12, 2019, at 4:05 PM, Alexander Murmann > wrote: > >> > >>

Re: Access to upload Apache Geode to Docker Hub.

Done On Tue, Nov 19, 2019 at 3:51 PM Mark Hanson wrote: > Hi, > > I would like to have access to upload to Docker Hub, so I can release > Apache Geode to Docker Hub. > > My DockerHub ID is mhansonp. > > Thanks, > Mark

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 wro

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

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 questi

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 actual

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 doi

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 advan

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

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 de

Re: [Vote] Include GEODE-7752 into 1.12

ssary pain to simplify 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

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 vot

Re: [DISCUSS] RFC: Shipping Geode patch releases

nches? How > 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 polic

Re: [DISCUSS] RFC: Shipping Geode patch releases

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

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,

[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: [DISCUSS] Adding Google Analytics to our website

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

Re: [DISCUSS] Adding Google Analytics to our website

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

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 > > with m

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 of

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 t

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

e or 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: 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 gran

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

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

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 wo

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 ass

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 bra

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

lity 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: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

is slowing 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 Distributed

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

Re: [Discuss] Cutting Geode 1.14

020 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 9:21 AM, Alexander Murmann > wrote: > > > > Hi everyone, > > > > TL;DR: Let's d

Re: [Discuss] Cutting Geode 1.14

t we may not know about yet. > > 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

Re: [Discuss] Cutting Geode 1.14

are in danger of being > exhausted by > > 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. > >

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

Re: [PROPOSAL] Postpone Geode 1.14

> list 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 th

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

  1   2   3   >