>
> 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 t
> 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, b
> 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: an
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? I
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 fetch
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 into
dle files.
>
> 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,
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 correctn
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
thin
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
ge 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
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 source
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 h
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 particular
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 proceed?
;
> 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 bu
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
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 of
ander Murmann" wrote:
> >>
> >> I wonder 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
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
-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
mu
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 issu
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 beg
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 t
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 li
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
> sk
in/pipelines/
> 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 ca
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, so
> 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 resu
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
> 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 a
> 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 cluster.
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 decla
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 must'
ision something like:
>
> 1. 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 h
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 ele
is Change.
~Patrick Rhomberg
[1] https://github.com/apache/geode/pull/2532
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` local
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 i
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,
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
&g
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:
>
&g
> > Without 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
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
change
t; 2-3 weeks ago, this was working fine. Now 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
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 migh
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, A
+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 c
+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
Belatedly...
During our investigation into the application of the FlakyTest category,
we ran the FlakyTest precheckin target approximately 1,500 times over this
past weekend. An abundance of these tests passed without failure. In my
opinion, this provides the base confidence in these tests, an
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.
>
>
Jul 2, 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 promot
Geode 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://concou
@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, the
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
runti
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 Eme
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
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
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 working on removing our depe
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
> wrote:
>
>
e codebase;
> am I correct in thinking 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 u
her email regarding the intent of
CacheElement.
Imagination is Change.
~Patrick Rhomberg
asses do not have a `name' 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
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 Lia
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 rem
+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 o
+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 configurati
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 ho
PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com>
> wrote:
>
> > +1
> >
> > On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote:
> >
> > > +1
> > >
> > > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg <
> prhomb...@pivotal.io>
will again touch a 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
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
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
> > wrote:
> >
> > > Hello all.
> > >
>
All,
I have added a section "Additional Concerns" addressing security and
concurrent use of the proposed interface.
Imagination is Change.
~Patrick
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., CacheC
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
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, Patrick Rhomberg
+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 t
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 varia
heavily 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
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 latest precheckin fai
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:
> I haven't seen this befor
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 wrote:
> +1 for
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
> forkevery 1 or if it's
+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 need to point the relevant branch to 'develop'
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
+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 in their GemFire builds
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
AcceptanceTes
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. I
-reproduce variety, so some leeway is deserved.
Two weeks? One month?
Thoughts?
Imagination is Change.
~Patrick Rhomberg
/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.
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
These problems stem from a dirty testing environment occupying the default
port, which this test wants to use. I have a pull request open to ignore
the test when the default port is not available.
On the one hand, an ignored test is essentially dead code. If the test is
consistently skipped and
> 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
ched)
<https://reviews.apache.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
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 for
> 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 li
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
/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
[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
emoved, 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.
- P
1 - 100 of 233 matches
Mail list logo
