Re: [DISCUSS] require reviews before merging a PR

> > I'm not sure it's possible to do this with the "reviewers" field - if > someone can figure out how to do this with the github IU, we can at least > try filing an ticket with apache infrastructure. > According to their docs [1], "collaborator with write access" is the GitHub required criteria

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

> Not sure if some people just force-push out of habit, or if the requirement for initial commit to be squashed creates some fear. If anyone here finds they have that habit, it would be a good one to break. > I would only do a rebase and force-push if github tells me that there is a > conflict,

Re: [DISCUSS] require reviews before merging a PR

> On May 30, 2019, at 4:47 PM, Owen Nichols wrote: > > Some folks have found it really helpful to have the PR author schedule a walk-through of the changes to give reviewers more context and explain the thinking behind the changes. I always thought this is what a good commit message should be:

Re: Remove mavenLocal from Geode gradle files

It is strange to me that your build is *only* looking in Maven-local. You're not building with --offline, are you? Does running with --refresh-dependencies resolve this issue when you have it? Is anything fiddling with your ~/.m2/repository without updating the corresponding maven xml entries?

Re: defunct branches

To elaborate on what Dan said: What has happened is that your local record of the remote references has 400+ remote branch references. Some time ago, I raised the same concern that you have here, and we got that number down to a couple dozen. But your local references are still there. git

[Geode Build] Are the idea and eclipse plugins being used by anyone?

I'm eyeballing the ide.gradle file we have and am wondering if it is cruft from many iterations of both Gradle and IntelliJ/Eclipse ago. In my own IntelliJ workflow, I have always just asked IntelliJ to open the gradle project via the build.gradle itself, and it's easy to import other modules

Re: Weird intermittent build error caused by spotlessJava

On Tue, Mar 26, 2019 at 2:49 PM Patrick Rhomberg > wrote: > > > As Dan mentioned, the few times I've seen this has been a result of > running > > clean in the same build set as spotless. While that "shouldn't" be an > > issue, it seems to be the underlying

Re: Weird intermittent build error caused by spotlessJava

As Dan mentioned, the few times I've seen this has been a result of running clean in the same build set as spotless. While that "shouldn't" be an issue, it seems to be the underlying cause. I encourage you to not clean every time you build. We've done a lot of work lately to improve the

Re: Geode 1.9 Release Manager

I would love for GEODE-6399 / PR #3190 to be included in this release. This PR resolves the earlier issues we had delegating dependencies to the geode-all-bom BOM and massively reduces the POMs for each module we publish. As it is, the published POMs are functional, and I understand that such

Re: Geode Version in the logs

You can write a custom log4j2.xml to configure logging to your heart's content. See Geode's and Log4j's documentation in [1] and [2] respectively. If the string you want to prepend is static, I'm pretty sure that can happen quite easily in a configuration XML. If it's dynamic, you might need to

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

conflicts on existing work. https://github.com/apache/geode/pull/3038 On Fri, Dec 21, 2018 at 3:43 PM Patrick Rhomberg wrote: > Yep. Sure does look like all the things you mentioned are true. > > The 'artifacts' configuration is a hold-over from the Legacy (a.k.a. > Gradle 1.0) publi

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

Yep. Sure does look like all the things you mentioned are true. The 'artifacts' configuration is a hold-over from the Legacy (a.k.a. Gradle 1.0) publishing, which I believe the Nexus plugin mimicked / used in its configuration. It looks like both the geode-pulse WAR not publishing and the

Re: Two copies of ExtendsFunctionAdapter.java

I agree that the Gradle is pathological in a lot of places. I've been working on correcting that for the last several months. It's slow going when you're restricted from breaking everything for a while. But it is getting better, for what it's worth. I can't tell from that stack-blob where you

Re: What is the new process for flaky test failures in precheckin?

For what it's worth, this specific failure (GEODE-6091) was a problem with the PR pipeline using an old test container image. This should have been corrected yesterday morning. On Mon, Nov 26, 2018 at 10:55 AM Helena Bales wrote: > For test failures that do not have a ticket for that

Re: AcceptanceTestOpenJDK11 precheckin fails to compile

I believe that the unable to access file: corrupted zip file indicates some transient failure in GCP? I remember seeing it in the past, but I don't think we ever got to the bottom of it. To respond to your other email, yeah, I think bumping your PR to re-fire might be the best way to

Re: Avoiding Unpredictability in Our DUnit Testing Rules

; VM server1 = host.getVM(startingVersion, 0); > > be frowned upon, if I use the above over using @Rule. > > Regards > Nabarun Nag > > > On Nov 21, 2018, at 10:36 AM, Robert Houghton > wrote: > > > > Great find, Patrick. I hope this shakes out some of the test bugs! &

Avoiding Unpredictability in Our DUnit Testing Rules

tl;dr: Use JUnit RuleChain. Hello all! Several [1] of our test @Rule classes make use of the fact that our DUnit VMs Host is statically accessible to affect every test VM. For instance, the SharedCountersRule initializes a counter in every VM, and the CleanupDUnitVMsRule bounces VMs before

Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest

I categorically like style improvement and enforcement. +1 to this specific style improvement and enforcement. It's pretty straight-forward to write a regex into our spotless.gradle. Let me know if you need a hand on that front, since I know I shouldn't use "straightforward" to refer to either

Re: Is concourse down?

if we somehow could find a way to make the error message > clearer. > >> Since it didn't merge cleanly, there is action I need to take as the > >> committer. However, I would never know that from the error message. > >> > >> On Mon, Nov 12, 2018 at 4:34

Re: Is concourse down?

See also the previous time this occurred. https://markmail.org/thread/apwupkbkg3qipygo On Mon, Nov 12, 2018 at 4:18 PM, Owen Nichols wrote: > This error usually means it didn’t merge cleanly, not that concourse is > “down" > > > On Nov 12, 2018, at 3:58 PM, Kirk Lund wrote: > > > > I'm trying

Re: [DISCUSS] Disable merge for failing pull requests

-1 I really don't think this needs to be codified. If people are merging red PRs, that is a failing as a responsible developer. Defensive programming is all well and good, but this seems like it's a bit beyond the pale in that regard. I foresee it making the correction of a red main pipeline

Re: Spotless Check failing on Windows?

Spotless has only been checking our gradle for maybe a week or two. It enforces dependency configurations using parentheses and single-quotes so they would be easier to sort while some of us made dependencies explicit. (Also, a future spotless improvement, once I can shake the bugs out). The

Apache Geode Branch Housekeeping

Hello all! We currently have 182 branches on the apache/geode repository. This is excessive. Please fork the main repository and save your branches there. If you must use the apache/geode repository for some reason, please be diligent in your removal of dead branches. *I would like to

Re: [DISCUSS] including Java11 in the pipelines

I agree with Jinmei on all points. I definitely think there should be parity between precheckin and the main pipeline, but that might just be because I caused the main pipeline to fail on Java11 this week. On Wed, Nov 7, 2018 at 1:34 PM, Jinmei Liao wrote: > First of all, I believe all gating

Questions about Poms and Publishing

Hello all! I've been working here and there on making each Geode module's dependencies explicit. Some previous discussion can be found in the archives [1]. My current question surrounds the structure of POMs in specifying version information. Gradle supports `dependency constraints` to unify

Re: [PROPOSAL] --add-opens for Java 11 support

In case anyone else's email broke the thread, below is a link to the previous thread in the mail archive for context. https://markmail.org/thread/xt224pvavxu3d54p On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao wrote: > We will need to wrap up this discussion with a decision. Looks like we are >

Re: Pull request precheckin not firing automatically

es/ > apache-develop-pr/jobs/AcceptanceTest/builds/293 > > Thanks, > Kirk > > On Wed, Oct 31, 2018 at 11:19 AM, Patrick Rhomberg > wrote: > > > Just to disseminate the knowledge... > > > > Although we like it when everyone just works nicely, you can check th

Re: Pull request precheckin not firing automatically

Just to disseminate the knowledge... Although we like it when everyone just works nicely, you can check the consumption of your PR in the Concourse by looking at the *geode* resource in the *apache-develop-pr* pipeline [1]. This resource passes the PR number and associated SHA to test against,

Re: About JIRA GEODE-5896

> Think I need finish the test code before create pull request. We have integrations into GitHub that launch precheckin testing in our continuous integration Concourse pipelines. PR status hooks updated when tests pass or fail. Of course, from a philosophical point of view, every bug is the

[Discuss] Where should simple classes for tests belong?

n the test class that consumes it (C-3 above) are packaged into resources via the JarBuilder class. [7] I look forward to hearing your opinions. Imagination is Change. ~Patrick Rhomberg Examples: [1] geode

Re: Running compatibility and upgrade tests using jdk9+

> If we throw away support for rolling JDK versions (which we’ve always supported) Looking at the documentation and our history of testing, I thought we've only supported Java8, since Geode 1.0. At Geode 1.5, the required JDK became Java 1.8.121, but this is significantly different than rolling

Re: Running compatibility and upgrade tests using jdk9+

> We need testing of Geode (both old and current versions) on older JVMs talking to Geode on newer JVMs. It would be nice to support this, but I'm not sure we should. We support rolling upgrades between versions of Geode, but I'm not convinced we should support JDK mismatch within a live

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I'm with Galen on this one. As nice as it would be to be able to say "This is what we'll do," I don't think any of these is going to be the proverbial silver bullet. I think we should, in priority order, (#1) remove what restricted API calls we can, (#2) adopt the module system and properly

Has anyone else been getting gradle "Unable to start the daemon process."

Hello all. I've been getting some strange failures lately, with the output given below. I have noticed that creating a `gradle wrapper` fixes these issues. However, since the gradle wrapper is part of the git tree, I was curious to know if anyone else was having this problem. If so, we

Re: [Discuss] Transitive dependencies and internal .pom changes

accept this PR > … > 2. introduce the java-library plugin and segregate dependencies into api > vs. implementation ones > … > N. define Java modules > > > On Fri, Sep 28, 2018 at 10:39 AM Patrick Rhomberg > wrote: > > > Bill has the heart of it, yes. > >

Re: [Discuss] Transitive dependencies and internal .pom changes

Bill has the heart of it, yes. I should have also mentioned that this ties into java-library plugin configuration, notably that the `compile` configuration is deprecated. For dependences that we do not wish to leak, we will need to use `implementation`. For dependencies which we intentionally

[Discuss] Transitive dependencies and internal .pom changes

. ~Patrick Rhomberg [1] https://github.com/apache/geode/pull/2532

Re: LoggingTest category

Tangentially related, we have a test-by-category.gradle. Is anyone using any of those targets? I suspect that many of these targets are no longer stable or correctly configured ever since we restructured tests around integrationTest / distributedTest / etc. Running `./gradlew securityTest`

Re: Concourse - max containers reached

Something appears to be up with the container garbage collector. Just to get things moving in the interim, we've restarted the workers to unceremoniously whack the containers that should have been pruned. Anyone with tests running may have had their tests workers die as a result. Sorry for the

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

be closed? > > > > Regards > > Nabarun Nag > > > > > > On Thu, Sep 13, 2018 at 9:21 AM Patrick Rhomberg > > wrote: > > > >> Sounds like we have a plan! I'll take it upon myself to do the revert. > >> > >> On Thu, Se

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

can be incorporated after > > discussions. > > > > Is it acceptable? > > > > Regards > > Nabarun Nag > > > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg > > wrote: > > > > > Okay. So that information is definitely coming from the > >

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

Wed Sep 12 16:07:56 PDT 2018 > Source-Date=2018-09-11 15\:56\:48 -0700 > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > Source-Repository=release/1.7.0 > > Hope this helps > > Regards > Nabarun Nag > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg > wrote: >

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

out the fix, the command "export cluster-config > > --zip-file-name=x.zip" > > > would fail with NPE, user has to use "export cluster-config > > > --zip-file-name=./x.zip" in order for export to work. > > > > > > PR for this fix is ready an

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

I'm not sure PR 2457 will help with an ignored .buildinfo, but I'm not sure as to why .buildinfo would be getting ignored by anything, either. PR 2457 deals with the still-needs-to-be-renamed GemFireVersion.properties file and when it is generated. Previously, it was whenever the git index

Re: spotless fails Apache license header?

it fails spotless, so > >>>> something changed. Maybe the version of spotless that we're using in > >>>> gradle? Or a gradle spotless plugin version changed? > >>>> > >>>> At best, it's laughable that our spotless format now complain

Re: spotless fails Apache license header?

The only addition with respect to spotless on the 10th was to add the `devBuild` target (which runs `spotlessApply`) and to require that `spotlessApply` would run before `compileJava`, if both were to run in a given build command. Looking at the PR against which these failed, it looks like it

Re: [DISCUSS] Which assert is the right one to use moving forward?

I greatly favor AssertJ-core's `assertThat` and `assertThatThrownBy`. Decoupling is nice, but the reported failure information that AssertJ includes makes investigating failures initially much easier. That, and method-chaining assertions and (rarely) soft-assertions are useful features. On Mon,

Re: Moving from gradle to maven

+1 to correcting our current broken gradle build. The fault, dear Brutus, is not in our [tools], but in ourselves. I think the root pain point is that our dependency tree is neither explicit nor correct in several places. I have myself had frequent issues surrounding our Protobuf and OQLLexer

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

+1 to a single source of member wait calls. We already have a standard set of await methods for DUnit member VMs, located in the MemberVM class, and delegated to that class from the MemberStarterRule. I have a PR outstanding [1] that improves those methods, too. For those awaits that are common

Re: Rat failure

We already have a rather extensive list of excludes in gradle/rat.spotless. Another "*.rendered" could be added. On Mon, Jul 2, 2018 at 1:05 PM, Anthony Baker wrote: > The GEODE_USER_DIR on jenkins is set to the workspace so it’s leaving > behind a notification file that causes rat to fail. >

Re: Requesting Pipeline Permissions

, 2018 at 12:08 PM, Patrick Rhomberg > wrote: > > > Hello all. > > > > I'm currently investigating the state of our FlakyTest consumption, > > believing that a lot of these markers are no longer accurate and that the > > annotated tests deserve promotion to the

Requesting Pipeline Permissions

pipelines. Thank you. Imagination is Change. ~Patrick Rhomberg [1] According to the script used to build the develop-metrics "pipeline", there have only been 10 (of ~90) flaky test classes that produced failures in the last 114 (currently all) FlakyTest job runs. See https://concourse.a

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

@Dale It seems to me that the Unit / Distributed / etc would be the more stable purpose, and as importantly, each level is mutually-exclusive with any other. At least under our current categorization tags, the functional area categories don't form a partition on our test set. For instance,

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

I like the idea of good structure around our test-complexity @Category layout. @Alexander, not to speak for Bruce, but to my mind things like SecurityTest / WanTest / etc are orthogonal to the UnitTest / IntegrationTest / DistributedTest / AcceptanceTest classification. I like adding better

Re: PR: Configure Spotless not to join already-wrapped lines

I know that you and I aren't the only ones who disliked how spotless disrupted method chains. Since it won't recognize chain vs non-chain context, we as developers will need to be more cognizant of this in general. But I still think it's a good tradeoff. On Thu, May 24, 2018 at 5:14 PM, Dale

[Proposal] Publicizing Extension et al for future consumption by the experimental Configuration Persistence Service (previously "Cluster Configuration Service")

API. Thoughts? Imagination is Change. ~Patrick Rhomberg. [1] https://cwiki.apache.org/confluence/display/GEODE/Extend ing+Geode+-+Creating+Custom%2C+Persisted+Cache+Configuration+Elements [2] https://cwiki.apache.org/confluence/pages/viewpage. action?pageId=75975896

Geode Build Changes Incoming -- Take care during merging!

fail in the pipeline after merging. Developers are encouraged to make sure they are not using wildcard imports and to build a merged branch locally before proceeding with the Squash And Merge available on GitHub. Thanks and happy coding! Imagination is Change. ~Patrick Rhomberg [1] https

Re: Better support for JSON gfsh results

I was under the impression that gfsh console output was intended as a more "active" interface with an operator. To that end, improved usability and a more consistent output sounds like a boon to me. On Tue, May 1, 2018 at 3:41 PM, Jens Deppe wrote: > Hi All, > > I'm

Re: [Discuss] Scope of the CacheElement interface with the respect to the public cluster configuration API

; identified as a CacheElement, but we don't have to go through all of the > objects and identify them at once. When we are refactoring each individual > commands and recognize the need, we will identify the object to be a > CacheElement. > > On Wed, Apr 25, 2018 at 3:41 PM, Patrick Rhomberg <

Re: [Discuss] Scope of the CacheElement interface with the respect to the public cluster configuration API

that you're referring to > org.apache.geode.cache.configuration.CacheElement? > > This class doesn't have a Javadoc, so it's a little hard as an outsider to > understand exactly what it is or how it's used. Can you explain the basics > of how it's used? > > Thanks, > > Galen > > >

[Proposal] Changes to the experimental cluster configuration API.

the intent of CacheElement. Imagination is Change. ~Patrick Rhomberg

[Discuss] Scope of the CacheElement interface with the respect to the public cluster configuration API

' or `id' field, making option (D) difficult. I like option (C), although we have already moved beyond that specification in our current iteration, with ConnectorService.RegionMapping implementing CacheElement. Thoughts? Imagination is Change. ~Patrick Rhomberg

Re: Index on Region

Some types / fields have their deprecation noted in their documentation, within the block. Alternatively / in addition, some xsd:element have the block deprecated Although I don't know if these annotations count as "visible," but they are there. On Mon, Apr 16, 2018 at 1:49 PM, Jinmei

Be careful with your merging after recent spotless changes.

Hello all! As of this morning, spotless has been updated to automatically remove unused imports. As a result, if you have been working on a branch from before that commit, it would be possible to have a green precheckin without merge conflicts that that could fail to build, if your changes

Re: [DISCUSS]: Tests requiring external services

+1. AcceptanceTest seems fittings, although... That test category was created with the focus on tests that run gfsh scripts via the GfshRule. Because the GfshRule uses the built jar and actually launches gfsh to run its tests, all current AcceptanceTests exist in geode-assembly. Perhaps as an

Re: [PROPOSAL] Deprecating DistributedSystem

+1 to deprecation. @John, The context in which the findMember methods are useful is (as far as I can tell) limited to commands being run on a locator. These methods will remain accessible via the new public API in the (currently @Experimental) GfshCommand abstract class. Likewise, the

Re: [DISCUSS] New List for Commit and CI Emails

I'm with Swapnil on this one. I think the way we make it less noisy is to take the time to fix the failing tests. I suppose we could split the difference and give the CI emails a, say, daily cadence. No news is good news, or else it gives you all the failures in the last 24 hours. Don't know

Re: [Discussion] Improving Spotless to be Even More Beautiful

r 19, 2018 at 4:17 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > +1 > > > > On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > +1 > > > > > > On Mon, Mar 19, 201

[Discussion] Improving Spotless to be Even More Beautiful

great many files, so it should be targeted for immediately following a release, perhaps the impending 1.5. It can pretty easily be exploded into several commits across each subproject and task for ease of review. Thoughts? Imagination is Change. ~Patrick Rhomberg

[Proposal] Gfsh Command Feature Flag Annotation

Hello, All I am interested in extending annotation functionality on our gfsh commands, particularly with respect to feature-flagging commands that are mutually-reliant or not yet feature complete. Please review the proposal [1] at your convenience. Imagination is Change. ~Patrick Rhomberg

Re: [PROPOSAL] Public API for Cluster Configuration

ng a group's configuration > is > > not cluster configuration. So I think updateCacheConfig is a better name > > than updateClusterConfig? > > > > On Mon, Mar 12, 2018 at 4:11 PM, Patrick Rhomberg <prhomb...@pivotal.io> > > wrote: > > > > >

Re: [PROPOSAL] Public API for Cluster Configuration

All, I have added a section "Additional Concerns" addressing security and concurrent use of the proposed interface. Imagination is Change. ~Patrick

[PROPOSAL] Public API for Cluster Configuration

Hello all. Please refer to the wiki page [1] for a proposal to expose modification of cluster configuration. In short, this proposes an endpoint for developers to modify or extend cluster configuration functionalities. This would eventually replace existing configuration classes (e.g.,

Requesting permission to add a proposal to the Geode Wiki

Hello all! I wanted to propose adding a public cluster configuration API, and I think that conversation would greatly benefit from the formatting that email too critically lacks. My username is prhomberg Imagination is Change. ~Patrick

Re: FunctionService Proposal

gion does not really mean "on the servers hosting region XXX". It only > executes on a subset of the servers, potentially with retries, until it has > covered that entire dataset once. So I think onRegion is more appropriate. > > -Dan > > On Wed, Mar 7, 2018 at 2:38 PM, Pa

Re: FunctionService Proposal

+1 for iteration towards better single responsibility design and more easily-digestible classes. Regarding method names, I think that there would be some good utility in having "onGroup" methods, as well. If we're not opposed to descriptive verbosity, I might prefer "onServersHostingRegion" more

Re: Starter tickets

I don't really think "newbie" has a negative connotation, but then again, I've been a gamer long enough to see a difference between terms "newb" and a "n00b." I do love consistency, though. (You might even say "consistency is a must.") We currently have tickets tagged with "newbie" and its

[Discuss] Member Launcher API

ly rely on visibility of class fields that would be otherwise inaccessible. Thoughts or concerns on these API relocations? Imagination is Change. ~Patrick Rhomberg [1] https://issues.apache.org/jira/browse/GEODE-3584

Re: Broken build?

I got a similar issue a while back. It was something weird about gradle caching, I think. If you're using `./gradlew clean installDist`, try using a pass of `./gradlew clean build` instead. That cleared it up for me. On Thu, Feb 22, 2018 at 4:07 PM, Kirk Lund wrote: > My

Re: travis build failing trying to download jpf

BitBucket is currently listed is "Degraded Performance" for a few things. Their metrics look like they've gotten slammed in the last hour or three. Hopefully that clears up soon... https://status.bitbucket.org/ On Tue, Jan 9, 2018 at 9:30 AM, Bruce Schuchardt wrote: >

Re: Handling files and user.dir in tests

The ClusterStartupRule, LocatorStarterRule, and ServerStarterRule rules all have withTempWorkingDir methods that should take care of this, as well. These temporary directories should be removed as part of the rules @After invocation. On Mon, Jan 8, 2018 at 10:23 AM, Jinmei Liao

Re: Debugging intermittent dunit failures

Are the AcceptanceTests currently set to fork after every one? It might be apples to oranges, but we could try to look at the cost difference there. On Thu, Dec 14, 2017 at 4:24 PM, Kirk Lund wrote: > Thanks Jens! Let us know if you end up running dunit in parallel with >

Re: Default branch for geode should be 'develop'

+1 for smoother workflow. On Mon, Dec 11, 2017 at 2:14 PM, Darrel Schneider wrote: > +1 > > On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe wrote: > > > Currently, github has the default branch for apache/geode set to > 'master'. > > (which is why you

Please remember to prune your branches from the GitHub repository.

to clean up after yourself. Alternatively, if you fork the apache/geode.git, your branches won't clutter the common area, as it were. Thanks. Imagination is Change. ~Patrick Rhomberg

Re: [DISCUSS] FunctionAdapter incompatible serialVersionUID

+1 to removing a long-deprecated class from the Geode side. On Tue, Nov 28, 2017 at 8:04 AM, Bruce Schuchardt wrote: > How about just getting rid of this class? After all it was marked as > being deprecated in 1.0. Pivotal could add a compatible FunctionAdapter > class

Test Coverage Mapping

Hello, all. While looking at expanding testing coverage, the natural question arose: what does the existing test coverage map look like? Does anyone know if we have an existing code-coverage analysis done as part of our testing? If there is, does anyone know if our DUnitTests or

Re: [DISCUSS] consistency of command result status

I definitely favor consistency along (what seems to me to be) common-sense divisions. I personally feel like an OK status should only occur when the command hits no hiccups that it can't resolve. We introduced the ExitCode class this past summer with the intent of unifying command exit status.

[DISCUSS] Maximum duration that a class may contain a @Flaky

-to-reproduce variety, so some leeway is deserved. Two weeks? One month? Thoughts? Imagination is Change. ~Patrick Rhomberg

Re: Review Request 62339: Will this preserve backwards compat?

/ResourcePermission.java Lines 78-91 (patched) <https://reviews.apache.org/r/62339/#comment261747> We had discussed moving towards a strictly-String API in any case. I didn't know if this should be marked `@Deprecated` or not as a result. - Patrick Rhomberg On Sept. 14, 2017, 7:05 p.m., P

Review Request 62339: Will this preserve backwards compat?

--- Will this preserve backwards compat? Diffs - geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 6a920d7c217f7383e38a7465540cdc0d542b6c81 Diff: https://reviews.apache.org/r/62339/diff/1/ Testing --- Thanks, Patrick Rhomberg

Re: Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

> On Sept. 7, 2017, 6:03 p.m., Patrick Rhomberg wrote: > > Overall: I love how much is getting pruned! > > > > I like to run inspections with the `Changed Files` scope to clean up some > > of the low-hanging fruit. In particular, I get rankled by > > * Missor

Re: Review Request 62163: GEODE-3096: pulling in refactoring work on HttpOperationInvoker

he.org/r/62163/#comment261045> This class was introduced but is unused? geode-junit/build.gradle Lines 26 (patched) <https://reviews.apache.org/r/62163/#comment261035> Do we need to start a thread on geode-dev about adding dependencies? Or is the JUnit module somewhat

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

Personally, I don't much like sentinel values, even if they have their occasional use. Do we need to provide an authentic infinite value? 64-bit MAXINT is nearly 10 quintillion. At 10GHz, that still takes almost three years. If each retry takes as much as 10ms, we're still looking at "retry

Re: Review Request 61972: GEODE-3445: Convert connect acceptance test to DUnit test

> On Aug. 29, 2017, 6:42 p.m., Patrick Rhomberg wrote: > > As an aside, I assume you post these things via script. You're still > > tagging `eyeh`. Not that it really matters, since it's hooked ot a > > `pivotal` email, but still worth updating. Also looks like you'

Re: Review Request 61972: GEODE-3445: Convert connect acceptance test to DUnit test

script. You're still tagging `eyeh`. Not that it really matters, since it's hooked ot a `pivotal` email, but still worth updating. - Patrick Rhomberg On Aug. 29, 2017, 4:53 p.m., Jared Stewart wrote: > > --- > This is an auto

Re: Review Request 61860: GEODE-3510: GfshRule displays output from StdError

/dunit/rules/gfsh/ProcessLogger.java Lines 24 (patched) <https://reviews.apache.org/r/61860/#comment259801> Left a straggler. - Patrick Rhomberg On Aug. 23, 2017, 8:18 p.m., Jared Stewart wrote: > > --- > This is a

[DISCUSS] Updating Spotless

[tl;dr:] - We are inconsistent with our own established style rules. - We should become not that. - How do we coordinate becoming better? - Do you have any other areas where we can become more spotless? -- Hello, devs. There are a great many instances throughout the geode codebase that

Re: Review Request 61701: GEODE-3277: Fix error path constructors of Launcher inner State classess

moved, along with the `// port = getRandomAvailablePort(SOCKET);` below geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java Lines 47-52 (original), 47-52 (patched) <https://reviews.apache.org/r/61701/#comment259689> A man after my own heart. - Patrick Rho

Re: geode-old-versions dependencies is slooooowwww

I am also in favor of skipping the download, but now I'm failing my build with All test reports at /.../build/reports/combined FAILURE: Build failed with an exception. * Where: Build file '/.../geode-old-versions/build.gradle' line: 60 * What went wrong: Execution failed for task

Re: Review Request 61757: GEODE-2859: Fix ShowDeadlockDUnitTest

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61757/#review183396 --- Ship it! Ship It! - Patrick Rhomberg On Aug. 18, 2017, 9:40

  1   2   3   >