Review for #4387

Hi all, please could someone review https://issues.apache.org/jira/browse/GEODE-7458 [GEODE-7458] Adding additional option in gfsh command "start gateway sender" to control clearing of existing queues - ASF JIRA This Jira has been LDAP enabled, i

Re: [REQUEST] Squash merge please

Whenever I submit a PR with multiple commits that I intend to rebase to develop, I always try to ensure that each commit stands alone as is (compiles and passes tests). Separating file renames and refactoring from behavior changes into different commits seems very valuable to me, and I've had troub

Re: [REQUEST] Squash merge please

Kirk, I believe that creating a Pull Request with multiple commits is ok. It's just in the end that when it's being pushed to develop branch, it needs to be squash merged. I believe that is what you have mentioned in the first paragraph, and I am more than happy with that. If you can see in the fir

Re: [REQUEST] Squash merge please

I would strongly prefer smaller as small a commit as possible. And as large as necessary. I am less partial when it comes to PRs sizes. Sometimes depending on what is done in a PR, I don’t think it makes sense to issue a blanket statement that all PRs are one commit. I think there is a strong re

Re: [REQUEST] Squash merge please

Hi Mark, I would like to limit the scope of the discussion to pushing PRs to develop as a squash and merge operation and not just merge. This is to keep the history linear and clean like other projects which will help with regression and cherry-pick (reference: first screenshot in the email chain)

Re: [REQUEST] Squash merge please

Once a PR is reviewed and merged, the remainder of its lifecycle could include a revert, a cherry-pick to another branch, or just browsing the git history. In general it’s most convenient for all of the above cases if 1 JIRA == 1 commit on develop. As a set-it-and-forget-it default, Squash and

Re: [REQUEST] Squash merge please

I'm not sure what this discussion is about... WE, as a community, have agreed in common practices, in two place no less... 1) Quoting our PR template For all changes: * Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? * Has your PR bee

Re: [REQUEST] Squash merge please

In addition to pointing this out.. I've found this... https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history I'm not sure that we need to enable this featur

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

-1 to adding a copy constructor onto any /**Factory*/ classes. I have never seen a copy constructor on a Factory pattern in the wild. That said, having done some Googling, this is something that people talk about, so it cannot be THAT foreign. There is one thing I want to point out here. Ther

Re: [REQUEST] Squash merge please

I think it's already resolved Udo ;) Here's the problem, if I fixup a dunit test by removing all uses of "this." and I rename the dunit test, then git doesn't remember that the file is a rename -- it forever afterwards interprets it as a new file that I created if I touch more than 50% of the line

[VOTE] Adding a couple user APIs dealing with RegionFactory.

Actually, I would say that it would not be necessary to have a copy constructor if it were not for the way the tests are written that assume an AttributesFactory. I think the discussion boils down to this… Do we migrate to the RegionFactory API from AttributesFactory or do we wait for the Manag

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

It has been said I have a negative vote which is counter intuitive. VOTE SUBJECT: Should we continue migrating from AttributesFactory usage to RegionFactory usage and merge the RegionFactory copy constructor. +1 to Migrate to RegionFactory from AttributesFactory and merge the RegionFactory co

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

Thanks, but it isn’t clear to me exactly what is at stake here. If this is a “design” level proposal, perhaps it should go through the RFC process rather than straight to a vote. Either way, a short summary of the problem description, the possible paths forward, and the advantages/disadvantage

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

A -1 vote on a code change should be framed as a “request for change”. Udo, you’ve made it clear what you don’t want, but not what it would take to make PR #4409 acceptable to you. “Management V2 API” is unlikely to solve all problems in the near term, and even to do so, it needs a sound under

Propose bringing GEODE-7530 to release/1.11.0

I propose backporting commit 49eefca5d5564a5d9459bd38e314947a8579c9b4 from develop to the current release branch. This fix has been on develop since Dec 5 with no issues. It is critical because without it, hang in gii/rebalance is possible when persistent AEQ is enabled. This issue is believe

Re: Propose bringing GEODE-7537 to release/1.11.0

Sorry, the correct ticket is GEODE-7537 . This was on the short list previously posted as fixes 1.11.0 is waiting for. > On Dec 16, 2019, at 2:12 PM, Owen Nichols wrote: > > I propose backporting this from develop to the current release branch

Re: Propose bringing GEODE-7537 to release/1.11.0

Yes, I agree, but I am waiting on a fix. Eric is supposed to let me know when he feels its good to go. Thanks, Mark > On Dec 16, 2019, at 2:32 PM, Owen Nichols wrote: > > Sorry, the correct ticket is GEODE-7537 > . This was on the short > li

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting it…by the end of this week if possible? > On Dec 11, 2019, at 4:19 PM, Mark Hanson wrote: > > Hi All, > > It does not look like we have an assignee for GEODE-7531. Any taker

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I'm working on this right now.. Will submit a PR for GEODE-7531 and GEODE-7159 (it is the similar change than 7531) shortly. --Udo On 12/16/19 2:45 PM, Owen Nichols wrote: Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting

Passed: apache/geode-native#2263 (dependabot/bundler/docs/geode-native-book-cpp/excon-0.71.0 - eac04d6)

Build Update for apache/geode-native - Build: #2263 Status: Passed Duration: 1 hr, 39 mins, and 23 secs Commit: eac04d6 (dependabot/bundler/docs/geode-native-book-cpp/excon-0.71.0) Author: dependabot[bot] Message: Bump excon from 0.65.0 to 0.71.0 in /docs/geode