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

ssue(s) quickly, a later branch point would be nice. If not... probably better to branch at a "not known bad" point. On 1/26/22, 1:03 PM, "Mark Hanson" wrote: First, I think I would suggest that we have someone cut a branch as suggested and see how long it actua

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

First, I think I would suggest that we have someone cut a branch as suggested and see how long it actually takes. Second, I would suggest we define a norm if we want to avoid this in the future. Third, I don't really like the risk of having this in, but I have only heard about performance cha

Re: PR to add unique ID to DUnit log output

I support Jens' change until something better is identified. I think just this minor change will have a big impact on our ability to decipher what is going on in dunit tests. Thanks for making the change Jens! Mark On 1/4/22, 10:44 AM, "Dale Emery" wrote: Hi Jens and all, A possibil

Re: @TestOnly or @VisibleForTesting

I generally see @VisibleForTesting used to change permissions of a private method, which is inaccessible to an external object, into a public method to allow a test to reach in and set or get fields within a class. I see it as an invaluable bridge between the reality of where we are now with ou

Re: [discuss] RFC for Geode Authentication Expiation and Re-Authentication

Hi Jinmei, How do you intend to address the "register interests and CQ"? Is that by unregistering or queueing? I think this RFC looks good. Thanks, Mark On 7/27/21, 2:26 PM, "Jinmei Liao" wrote: Calling more feedback on this RFC. I will move this to “Under Development” if no objection

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

+1 to new report from Owen +1 to re-introduce the stress-test Great ideas Naba! On 6/10/21, 9:50 AM, "Nabarun Nag" wrote: Hi all, * We need to discuss how to prevent more flaky tests to be introduced now that stress-test is not mandatory for PRs to be merged? Reviewers checking

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

e sure the checks are still passing. On 6/9/21, 10:56 AM, "Mark Hanson" wrote: I think that process is a bit much. PRs are already a challenge. What do people think about code owners being the gate. We can accept by custom that there should be no stress-new-test failures. If

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

would have to wait for any running PR checks to complete, as well as remember to come back and look at the PR after any subsequent commits to make sure the checks are still passing. On 6/9/21, 10:56 AM, "Mark Hanson" wrote: I think that process is a bit much. PRs are alrea

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

ete, as well as remember to come back and look at the PR after any subsequent commits to make sure the checks are still passing. On 6/9/21, 10:56 AM, "Mark Hanson" wrote: I think that process is a bit much. PRs are already a challenge. What do people think about code owne

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I think that process is a bit much. PRs are already a challenge. What do people think about code owners being the gate. We can accept by custom that there should be no stress-new-test failures. If there is a failure, a code owner can request a change or decide to let it go. I think that is suffi

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

One other thing to think about is perhaps having a rotating team to deal with flaky tests, a small team commissioned every three or 6 months to clear out flaky tests for 1 month. It is good experience Thanks, Mark On 6/9/21, 10:04 AM, "Mark Hanson" wrote: One other thing

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

One other thing is that we have code owners. If the PR submitter decides to ignore the stress new test, the code owner can still request a fix. That is probably a sufficient process. On 6/9/21, 10:02 AM, "Mark Hanson" wrote: I agree, I am willing to concede this discussion, as

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I agree, I am willing to concede this discussion, as long as we are judicious and specifically only use it when it is not our test that is failing. It is a real problem. Thanks, Mark On 6/9/21, 9:46 AM, "Kirk Lund" wrote: I did think about splitting up dunit tests, but I believe testE

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I think the basic problem is that we have too much tech debt in the form of dunit tests. We are proposing all of these "workarounds" to avoid dealing with the core problem. On 6/8/21, 12:09 PM, "Dan Smith" wrote: Would it be possible to just split that test up into multiple classes? It s

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I understand the challenge, but I disagree. It is only through requirement that we keep new flakey tests out. While I don't think one should have to fix all the flaky tests to get their unrelated change in, I think it serves a purpose. IMHO, the problems that you are seeing are indications that

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

I think the key difference between what Bill and Jake are saying is that Bill is saying a new feature needs approval in a more structured way. I think Bill's process is open the jira, then it is "approved" or "won't do" then work starts. I think what Jake is saying is a little less structured. T

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

te on this... Are we saying; if I (geode dev) find a bug or feature that I need for my application, I need to get approval to create a ticket and work on it? We already have RFC process, won't that suffice... -Anil. On 5/28/21, 10:36 AM, "Mark Hanson" wrote: Hi All

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

Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark

Re: Reminder to use draft mode

repo) but it seems github does not allow to configure draft PRs as default option for a given repository. ____ De: Mark Hanson Enviado: viernes, 7 de mayo de 2021 23:06 Para: dev@geode.apache.org ; Blake Bender Asunto: Re: Reminder to use

Re: Reminder to use draft mode

real problem. I don't think it will be a significant one if the consensus is we start with draft PRs. Thanks, Mark On 5/7/21, 2:03 PM, "Mark Hanson" wrote: @Blake Bender The same goes for the geode code. The PR pipeline is *the* way to know if we broke something or not. Mo

Re: Reminder to use draft mode

@Blake Bender The same goes for the geode code. The PR pipeline is *the* way to know if we broke something or not. Most people don't know how to run the individual tests. Thanks, Mark On 5/7/21, 10:07 AM, "Blake Bender" wrote: +1 for draft mode as default. I'm forever switching to it in

Re: Reminder to use draft mode

I have a thought. What if draft mode was the default state for the PR button and you had to select normal mode for the PR button? Anyway, just my take. Thanks, Mark On 5/6/21, 10:45 AM, "Mark Hanson" wrote: I agree, I like the draft mode switch. The hesitations that

Re: Reminder to use draft mode

I agree, I like the draft mode switch. The hesitations that I have are mentioned by Jens in that you can have failures that are unrelated. Especially DUnits at this point. Perhaps for required tests following the draft mode approach is better. I have had many cases where I see PRs that obviously

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congratulations Kamilla! On 4/19/21, 2:33 PM, "Sarah Abbey" wrote: Congratulations, Kamilla!!! From: Ernie Burghardt Sent: Monday, April 19, 2021 5:22 PM To: dev@geode.apache.org Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Re: [VOTE] Requiring final keyword on every parameter and local variable

ptTime == 0); } Note: the code actually warns about getGemfireCache() being deprecated. Thanks, Mark On 4/19/21, 11:08 AM, "Mark Hanson" wrote: Hi Jake, I agree with everyone's point about final being a useful, I just don't find it useful enough to do anything

Re: [VOTE] Requiring final keyword on every parameter and local variable

Hi Jake, I agree with everyone's point about final being a useful, I just don't find it useful enough to do anything manually across the code base at this point. I believe first in foremost in no code warnings. Intellij warns about variables that can be final, so I make them final as it finds t

Re: Stats deprecations?

ly, there is no reason not to change the calls to incLong, getLong, etc. I'd say go for it. -Dan ____ From: Mark Hanson Sent: Wednesday, April 14, 2021 3:43 PM To: dev@geode.apache.org Subject: Stats deprecations? Hi, So I am makin

Stats deprecations?

Hi, So I am making some stats changes that are pretty minor, but I was looking at the fact that we have a ton of deprecated stuff about incInt and getInt. Can we convert those to longs? This would mean changing storage and return types. Thanks, Mark

Re: [VOTE] Requiring final keyword on every parameter and local variable

+1 To Kirk’s approach. -1 To final everywhere. I support Kirk’s approach of adding final where there is benefit. If we want to go further, we can have intellij find all of them and change them if we want. Final is not always a developer’s explicit statement. Sometimes something becomes final af

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

-1 for plugins +1 for deletion. I think we should make an effort to document our existing protocol before we bother worrying about supporting a second one. Blake and I have a Wireshark filter that is the tiniest step in that direction in one sense. I think taking larger steps in that direction

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 its removal. I was working on improving the geode thread monitor and found doing that on the protobuf code was much more complicated. From: Bruce Schuchardt Sent: Tu

Re: [Suspected Spam] RE: [VOTE] Apache Geode 1.13.2.RC1

+1 for release. Fixed a spelling error in release notes. Tested release Thanks, Mark On 3/16/21, 10:31 AM, "Dick Cavender" wrote: Please vote by 3pm today for 1.13.2. At this time we don't have enough votes to release although there are no -1s. From: Dick Cavender Sent: Thursda

[Proposal] Backport GEODE-8886 to 1.14

Hi All, It was discovered that there was a bug with unprocessed events under certain conditions with WAN specifically when old and new servers are vying for primary status. This fix will alleviate the problem in 1.14. The code that caused the problem is present in 1.14, hence the backport reque

Re: [Suspected Spam] [PROPOSAL] backport GEODE-8998 to 1.14

+1 On 3/3/21, 5:18 PM, "Darrel Schneider" wrote: I would like to backport GEODE-8998 to 1.14. If fixes an NPE that will cause the geode cluster to not be able to do any cluster messaging if thread monitoring is disabled. This bug has never been released so it would be nice k

Re: [Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

+1 On 3/3/21, 10:24 AM, "Jianxia Chen" wrote: I would like to backport the fix of GEODE-8671, currently a 1.14 blocker, to support/1.14, support 1.13 and support/1.12. This would help avoid Pdx corruption. Thanks, Jianxia

[Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

I would like to backport GEODE-8958 into previous release branches to alleviate a problem with tombstones if timestamps become corrupt for some reason. Thanks, Mark

Re: code-owners seems to have some problems

t needs review, will have text in the "reviewers needed and status-required" area, that states who is still needed to review. However, there is not a direct way to see if a co-owner has already reviewed a file you are looking at. -Robert On 2/25/21, 10:36 AM, "Mark Ha

Re: code-owners seems to have some problems

en Nichols" wrote: GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs (until you mark it not-draft by clicking Ready For Review). However if you subsequently change it back to a draft, GitHub will not remove any reviewers. On 2/25/21, 10:28 AM, "Mark Hanson&

Re: code-owners seems to have some problems

Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your

Re: Geode Quarterly Report DRAFT for your review

Hi Dave, Does the 110 committers number include PMC members? If so, that 2:1 doesn't line up. It would be more like 1:1. Thanks, Mark On 2/8/21, 12:13 PM, "Dave Barnes" wrote: Revised Committer-to-PMC ratio to 2:1 (thanks, Karen) On Mon, Feb 8, 2021 at 12:09 PM Dave Barnes wrote:

Re: [DISCUSS] Geode 1.14

I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a win

Re: PR pending review

Hi Ashish, Most of the team are on holiday at this point, so it is going to take a while before they will respond. I will review your PRs today, though I am not a subject matter expert on either of these areas. Thanks, Mark On 12/17/20, 6:40 AM, "aashish choudhary" wrote: Hi, Can

Re: Committing broken javadocs to develop

Can we make lack of comments an error? On 11/20/20, 4:47 PM, "Jacob Barrett" wrote: I think we can make javadoc warnings an error in Gradle. I have fixed several modules to treat java warnings as errors already. Perhaps we can just extend that effort. > On Nov 20, 2020, at 10:39 AM,

Re: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1

+1 On 10/21/20, 9:16 AM, "Aaron Lindsey" wrote: +1 Aaron > On Oct 21, 2020, at 9:00 AM, Donal Evans wrote: > > Hi Geode dev, > > I would like to backport the fix for https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbr

Re: [Proposal] Backport GEODE-8422 to support/1.13

I just cherry-picked the change in. Thanks! On 8/13/20, 4:55 PM, "Dick Cavender" wrote: +1 -Original Message- From: Mark Hanson Sent: Thursday, August 13, 2020 4:46 PM To: dev@geode.apache.org Subject: Re: [Proposal] Backport GEODE-8422 to su

Re: [Proposal] Backport GEODE-8422 to support/1.13

+1 On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson wrote: > Hi All, > > We have found a case where tombstones were being cleared when the region > was not initialized. This was causing some test failures and potential > field fai

Re: [Proposal] Backport GEODE-8422 to support/1.13

hanks, Mark On 8/13/20, 9:29 AM, "Mark Hanson" wrote: Yes. On 8/13/20, 7:27 AM, "Dave Barnes" wrote: Do I understand correctly that this fix, if validated, addresses the last remaining release-blocker for 1.13? On Wed, Aug 12, 2020 at 6

Re: [Proposal] Backport GEODE-8422 to support/1.13

Yes. On 8/13/20, 7:27 AM, "Dave Barnes" wrote: Do I understand correctly that this fix, if validated, addresses the last remaining release-blocker for 1.13? On Wed, Aug 12, 2020 at 6:02 PM Mark Hanson wrote: > Not yet, we will need to wait for that to finish cle

Re: [Proposal] Backport GEODE-8422 to support/1.13

ion on the develop branch completed a test cycle? On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen wrote: > +1 > > On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson wrote: > > > Hi All, > > > > We have found a case where tombstones were being

[Proposal] Backport GEODE-8422 to support/1.13

Hi All, We have found a case where tombstones were being cleared when the region was not initialized. This was causing some test failures and potential field failures. We would like to put this into support/1.13. Thanks, Mark

Re: [PROPOSAL] Postpone Geode 1.14

+1 to Michael's suggestion. On 7/31/20, 5:38 PM, "Michael Oleske" wrote: Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released,

Re: [Discuss] Cutting Geode 1.14

Playing devil's advocate here, but I think the reason we would not like to move to 1.14 would be that we have a ton testing already in to quantify issues on 1.13 and 1.14 would be (a bit) of an unknown quantity. Further, the core issues that we are waiting on for 1.13 are presumable 1.14 issues

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

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

Re: geode docker question

ver1'" -c "" Thanks, Mark On 7/7/20, 10:42 AM, "Mark Hanson" wrote: Hi Barry, Are you looking for something like this? docker run -it -v $(pwd):/apache_geode openjdk:8 sh -c "apache-geode/bin/gfsh -e "start locator --name=Locator1" -e

Re: geode docker question

Hi Barry, Are you looking for something like this? docker run -it -v $(pwd):/apache_geode openjdk:8 sh -c "apache-geode/bin/gfsh -e "start locator --name=Locator1" -e "start server --name=Server1" ^ shared location ^ not sure this pat

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

ease rather than having a semi-complete feature in 1.13 and forcing the > REST component to wait for a later release. > >From: Mark Hanson >Sent: Friday, June 26, 2020 10:06 AM >To: dev@geode.apache.org >Subject: [Proposal] Ad

[Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

Hello All, The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release. What do people think? Thanks, Mark

Re: Fate of master branch

+1 to delete. No good reason to keep it that I know of. I think I am the third +1 with no -1s so just do it. Thanks, Mark > On Jun 26, 2020, at 9:13 AM, Alexander Murmann wrote: > > +1 to deleting. Given we tag everything properly on the other branches, I > don't see the need for it either. >

Re: [PROPOSAL] Add windows jobs to PR checks

I support adding it in, but I think the time wasted is less than you think. I think for me the most important thing is finding an issue when it is put in. I think the current way is actually faster and more efficient, because every PR doesn’t have to wait the 4 hours and in reality the number is

Re: [PROPOSAL] Add windows jobs to PR checks

This is going to hurt timewise, but +1. > On Jun 25, 2020, at 10:11 AM, Kirk Lund wrote: > > Another option: > > (5) introduce a new staging branch that PRs merge directly to. Windows > testing occurs on this staging branch. Then any PRs that pass on the > staging branch can then be merged or c

[INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

FYI, the build success rate was around 90% or so about two months ago. Here are the DUnit tests that are currently failing in our tests, most likely in CI, and PR pipelines. Please let me know if you have any questions. Thanks, Mark

Re: Setting your commit email address

I think that is a fair point. On 6/18/20, 3:43 PM, "Jacob Barrett" wrote: Regardless of the email address issue, you can go to the commit and make comments and @johndoe and they will get a notification. -Jake > On Jun 18, 2020, at 10:31 AM, Kirk Lund wrote: > > I gues

Re: Setting your commit email address

Hi All, Just my opinion here, but I think that if you commit something that breaks CI, I should be able e-mail you at the email address on your commit. Thanks, Mark On 6/18/20, 10:31 AM, "Kirk Lund" wrote: I guess my main point is that I don't like private emails in OSS commit messa

Re: Refactor to Restore Redundancy Command for 1.13?

provals to add this to 1.13. Go ahead, Mark. On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior wrote: > Yes, +1 on this change. > > Joris > ____ > From: Mark Hanson > Sent: June 15, 2020 16:30 > To: dev@geod

Re: Refactor to Restore Redundancy Command for 1.13?

a=02%7C01%7Chansonm%40vmware.com%7C74f35d1e72eb4bc9794508d8116a9a68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637278496841068169&sdata=XERMUyRvB90LNSUvMMNCPJhB4fiAzEc%2FMrfST%2B2n5bI%3D&reserved=0> > > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson > wrote: > Hi All, >

Refactor to Restore Redundancy Command for 1.13?

Hi All, So we are working on refactoring the Restore Redundancy gfsh command code and we have made a change to a class that is getting serialized. We are curious if this is something we could maybe get into 1.13 ( the first release of this command? Or should we just make our serialization/deser

[INFO] Distributed Test runs in bulk results.

Hello All, I have been doing bulk test runs of DistributedTestOpenJDK8, in this case over 200. Here is a simplified report to kind of help you see what I am seeing and I think everybody sees with random failures as part of the PR process. It is very easy to cause failures like this by not knowi

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

There is also one other positive of having it in the ASF repo which is visibility to other people committing breaking changes. That might help with coordination. Thanks, Mark On 6/3/20, 10:51 AM, "Nabarun Nag" wrote: Thank you Aaron. We will continue using feature branch in ASF rep

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

While I am not 100% sure, I understand your thoughts here, I am pretty sure I do. We have already done such work in a branch in a fork (Micrometer work). The only real gotcha was that there needed to be one person at least as a collaborator, in case of vacations and such. All of the things you

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

+1. The more we can automate this types of checks the better. Thanks, Mark

Re: Over usage of @SuppressWarnings

It is slightly different, but here is a case I recently found. List versionTags = versions.getVersionTags(); This method is internal though. public List getVersionTags() { return Collections.unmodifiableList(this.versionTags); } Thanks, Mark > On May 8, 2020, at 1:25 PM, Mark Hanson wr

Re: Over usage of @SuppressWarnings

How does everyone feel about situations involving raw types? Such as public interface A is returning Region and not Region is that an acceptable suppression? Thanks, Mark > On May 8, 2020, at 1:20 PM, John Blum wrote: > > Agreed, but the following (inside tests) does not work in all cases, i.

Re: [DISCUSS] etiquette around breaking the pipeline

As far as I am aware, I think this is already a settled decision. The decision was quick revert. In almost every case the build is more important than the change. Thanks, Mark > On Apr 29, 2020, at 4:14 PM, Robert Houghton wrote: > > I am very pro-revert for breaking changes. The Benchmark or

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

>> } >> >> -j >> >> On Tue, Apr 14, 2020 at 3:21 PM Jason Huynh wrote: >> >>> The isClosed flag and method might be used currently more as an >> isClosing. >>> The GemFireCacheImpl.isClosed() method is actually returning isClosing. >>

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

) - Closes and waits until it is really closed. Option 5: Cache.close(Runnable closedCalleback) - Runs callback after cache is really close. Option 6: cache.close(); while (!cache.isClosed()); > On Apr 14, 2020, at 2:11 PM, Mark Hanson wrote: > > Hi All, > > I know that we have disc

Re: [Discuss] Cache.close is not synchronous, but code still expects it to be....

Corrected subject line... > On Apr 14, 2020, at 2:11 PM, Mark Hanson wrote: > > Hi All, > > I know that we have discussed this once before, but I think it bears > repeating. We have test code that assumes cache.close is synchronous. It is > not. Not even close. I wo

[Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

Hi All, I know that we have discussed this once before, but I think it bears repeating. We have test code that assumes cache.close is synchronous. It is not. Not even close. I would like discuss some possible changes. Option 1. Call it what it is. Deprecate Cache.close and create a new method

Re: [DISCUSS] Replace UDP messaging for membership with TCP

Can we document the protocol this time? Thanks, Mark > On Mar 31, 2020, at 10:17 AM, Dan Smith wrote: > > Hi all, > > We created a RFC for replacing our UDP messaging in Geode with a TCP based > solution. This will address the issues we have supporting our current udp > encryption solution, a

Re: Help needed to get my PR to pass the stressNewTest

Hi Eric, When you have a moment, ping me. I can help. I think… Thanks, Mark > On Mar 4, 2020, at 1:27 PM, Eric Shu wrote: > > My PR (https://github.com/apache/geode/pull/4709) continue to fail in > stressNewTest. I have been retrigger the test and all failed with same > issue. I need help to

Re: PR Titles

; is buried at the bottom and is > an important signal being lost in the noise... > > On Mon, Mar 2, 2020 at 10:12 AM Jacob Barrett wrote: > >> >> >>> On Mar 2, 2020, at 10:10 AM, Mark Hanson wrote: >>> >>> If I may add one caveat. If a pull re

Re: PR Titles

If I may add one caveat. If a pull request is in a ready to review state … . If it is prefaced with Do Not Review: then . Thanks, Mark > On Mar 2, 2020, at 9:30 AM, Alexander Murmann wrote: > >> >> Don't we have a published checklist or guideline or something for this >> already? Including s

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

gt;>>> with 50 repeats if fewer than 25 files changed, otherwise compute 1250 / >>>> <#-files-changed> and do only that many repeats (e.g. if 50 files >> changed, >>>> run all tests 25x instead of 50x). >>>> >>>> While StressNe

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

run all tests 25x instead of 50x). >> >> While StressNew is intended to catch new flaky tests, it can also catch >> poorly-designed tests that fail just by running twice in the same VM. This >> may be a sign that the test does not clean up properly and could be >> pol

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

Hi All, Proposal: Force StressNewTest to fail a change with 25 or more files rather than pass it without running it. Currently, the StressNewTest job in the pipeline will just pass a job that has more than 25 files changed. It will be marked as green with no work done. There are reasons, relat

[Question] I had a PR that didn't run a StressNewTestOpenJDK11(really), but passed?

Hi, Why is that? It gave the error message in the log of " 17:26:13 66 changed tests 17:26:13 66 is too many changed tests to stress test. Allowing this job to pass without stress testing.” I didn’t touch 66 files. I touched 5 classes. It maybe that there are 66 tests therein, but if that is t

Re: [Vote] Include GEODE-7752 into 1.12

Hi Ernie, Thanks for the heads up. This is breaking DistributedTestOpenJDK and Udo confirmed the are of concern and is going to revert this. Thanks, Mark > On Feb 5, 2020, at 4:14 PM, Ernest Burghardt wrote: > > Udo, > the PR has some failing tests that are in the "non-mandatory" category fo

Question regarding a ConnectionPoolDUnitTest failure

Hi All, I could use a little help understanding the expected behavior for a test case. We are registering for events and we are getting destroys for destroys, creates for creates etc. However, in the case of a recreate, it seems like we are getting an entry event of LOCAL_LOAD_CREATE and some

Release Manager for 1.12.0: We have a volunteer!

Hi All, Ernest Burghardt (@echobravopapa on github) has volunteered to take on the Release Manager responsibilities for 1.12.0. Thank you Ernie! Best regards, Mark

A Release Hero/Manager is needed for 1.12 (February 3rd)

Just a reminder, still looking for that release manager… Please don’t all volunteer at once! Glory and street cred await the intrepid release manager volunteer. Hello All, It is that time again. It is time to cut a new release branch for 1.12 on February 3rd. We need a volunteer! No experie

Re: [DISCUSS] include geode-benchmarks in 1.12 release

Just my two cents. I think that we should probably strip CI into a separate repo. The key indicator is that if something were wrong in the CI yaml, would I hold a release for that? I think no. So that suggests to me it is a separate thing. Same goes for benchmarks. If we were failing a benchmar

Release Manager for 1.12 (February 3rd)

Hello All, It is that time again. It is time to cut a new release branch for 1.12 on February 3rd. We need a volunteer! No experience required. Committer status would be helpful, but not required. In the mean time, we should focus on ensuring the CI is stable and start planning to cut the bra

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

; wrote: >> >>> 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 >&g

[DISCUSS] Someone to update 3rd-party libraries used by GEODE

code. We would need to get this done within the next week or two, so that we have time to shake out issues before the next release. Regards, Mark Hanson on behalf of the Apache Geode team

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

gt; merge >>>>>> options >>>>>>>>> from GitHub, leaving only Squash and Merge. PR #4513 >>>>>>>>> <https://github.com/apache/geode/pull/4513> serves as an >> exhibit >>>> of >>>>>>>

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

gt;>> at random. >>>>> - I'd rather be deliberate about what tests we introduce than >>> wholesale >>>>> bring back a set of tests, since any of these re-introduced tests >>> has a >>>>> potential to be flaky.

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

Hi All, As part of what I am doing to fix flaky tests, I periodically come across tests that are @Ignore’d. I am curious what we would like to do with them generally speaking. We could fix them, which would seem obvious, but we are struggling to fix flaky tests as it is. We could delete them,

[ANNOUNCE] Apache Geode 1.11.0

website:http://geode.apache.org/releases/ The release documentation is available at:http://geode.apache.org/docs/guide/111/about_geode.html We would like to thank all the contributors that made the release possible. Regards, Mark Hanson on behalf of the Apache Geode team

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

This change to disable all but squash-merge would be really easy to revert. How about we try it for a while and see? If people decide it is really limiting them, we can change it back. Let’s do it for 1 month and see how it goes. Does that sound reasonable? Thanks, Mark > On Dec 30, 2019, at 5

Re: [VOTE] Apache Geode 1.11.0.RC4

Hi All, It seems that we have the 3 PMC member votes needed plus extra votes, so I will begin the release process for Apache Geode 1.11.0.RC4, once cwiki.apache.org comes back online. Final tallies appear to be. 5 +1 (Yes, release it.) 1 -0 (Releasing is OK, but…

Re: [VOTE] Apache Geode 1.11.0.RC4

Given it is the holidays, perhaps more time is in order. I am bumping the voting deadline to Friday, December 27th, 2019. Thanks, Mark > On Dec 20, 2019, at 2:46 PM, Mark Hanson wrote: > > Subject: [VOTE] Apache Geode 1.11.0.RC4 > Hello Geode Dev Community, > > This is a

  1   2   3   >