Re: Geode Version in the logs

[Nabarun Nag]

Just in case you are planning to write tests consisting of multiple
versions of Apache Geode simultaneously, you can look into any
RollingUpgradeDUnitTest. Those append the version number before each log
statement.

Regards
Nabarun Nag

On Thu, Jan 3, 2019 at 8:53 AM Jacob Barrett  wrote:

> Given that the version can’t change at runtime it doesn’t make sense to
> repeatedly print static state of the system. The log does print the static
> state of the system at startup.
>
> > On Jan 3, 2019, at 8:17 AM, Peter Tran  wrote:
> >
> > Hello,
> >
> > Is it possible to prepend every log message with the current Geode
> version?
> > I think it might help with debugging. I'm not sure how something like
> this
> > would work as the software wouldn't really know how to read metadata
> about
> > itself?
> >
> > Has something like this been attempted in the past? I would love your
> > opinion on the feasibility of this feature
> >
> > Thank you!
> > --
> > Peter Tran
>

Re: Extremely long IntelliJ Gradle refresh times

[Nabarun Nag]

I have not experienced this but , for it does take a long time (but not
60min) after an  IntelliJ update or invalidating IntelliJ caches. That time
it indexes all the Java , maven and gradle caches , sources and jars.
Subsequent refreshes are faster. Also increasing IntelliJ memory to 8g
helps.

Regards
Naba

On Wed, Jan 9, 2019 at 6:18 AM Jens Deppe  wrote:

> Is anyone else experiencing very long Gradle refresh times in IntelliJ?
> Mine currently takes almost 60 minutes! I'm on IJ 2018.3.2. (I'm pretty
> sure that I'm not hitting this problem
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_38209851_intellij-2Didea-2Dtakes-2Da-2Dlong-2Dtime-2Dwhen-2Drefreshing-2Da-2Dgradle-2Dproject&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=RhR9iLMRVV3bMiC6y-7JXA&m=XxuxfJ7cNHB5bGsLO0s9zpPOi7B7Dbwbs62QaeO9Uco&s=Wqkgk0evR68m0Y58RX0Qhlyem0P_xQZpb9NRwjEQ2e4&e=
> ).
>
> Actually, it's probably purely a Gradle problem: doing ./gradlew
> extensions:geode-modules:dependencies takes 3 1/2 minutes. Multiply that
> for every sub-module we have...
>

Re: Very red CI -> Hold merges, please

[Nabarun Nag]

FYI, I have just merged a ci timeout fix to increase the timeout for
geode-benchmarks to 4h. This does not influence any geode modules.

Regards
Naba

On Thu, Feb 7, 2019 at 9:32 AM Alexander Murmann 
wrote:

> Hi folks,
>
> Our CI is very red since ~24 hours
> <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/372
> >.
> It looks like a substantial new issue was introduced.
>
> Can we hold off on merging new changes to the develop branch till this
> issue is resolved?
>
> Thank you all!
>

Re: Geode 1.9 Release Manager

[Nabarun Nag]

I think also GEODE-6391, which is to fix a NPE while propagating región
destroy and invalidate region messages.

Regards
Naba


On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh  wrote:

> I think Kirk's topic and any solution related to stats (int to long) should
> be resolved before cutting the branch?
>
> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann 
> wrote:
>
> > If there are no other takers, I can act as release manager for 1.9 and
> will
> > cut a release branch this week.
> >
> >
> > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann 
> > wrote:
> >
> > > Hi everyone!
> > >
> > > February 1st is approaching rapidly which means it's almost time to cut
> > > the 1.9 release. Who is interested in being the release manager for
> 1.9?
> > >
> > > Thank you!
> > >
> >
>

Re: Geode 1.9 Release Manager

[Nabarun Nag]

I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into the release
branch.

For the second part, I am not sure how it was determined that fixes for
GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of introducing
more failures. Are we lacking tests , reviews  etc. I apologize but I was
not able to understand.

Regards
Nabarun

On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann 
wrote:

> Usually I am a proponent of cutting a branch and then fixing things on
> there where things are more stable. In this case we seem to have a large
> number of fairly serious concerns. Do we think the cost of putting this
> many fixes on develop + the release branch out-weights the benefit of less
> risk of new issues being introduced?
>
> Thoughts?
>
> Thank you, Sai for taking over!
>
> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> sai.boorlaga...@gmail.com>
> wrote:
>
> > I volunteer to be the release manager for 1.9.
> >
> > Sai
> >
> > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann 
> > wrote:
> >
> > > If there are no other takers, I can act as release manager for 1.9 and
> > will
> > > cut a release branch this week.
> > >
> > >
> > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann  >
> > > wrote:
> > >
> > > > Hi everyone!
> > > >
> > > > February 1st is approaching rapidly which means it's almost time to
> cut
> > > > the 1.9 release. Who is interested in being the release manager for
> > 1.9?
> > > >
> > > > Thank you!
> > > >
> > >
> >
>

Re: Geode 1.9 Release Manager

[Nabarun Nag]

I could not find any DISCUSS mails about not blocking a release. I may be
wrong, I apologize for that but could point me to the mail / documentation
about the release management.

Regards
Naba

On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda 
wrote:

> Did we not agreed that we won't be blocking a release to include fixes as
> we are in a fixed release schedule?
>
>
> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann 
> wrote:
>
> > Usually I am a proponent of cutting a branch and then fixing things on
> > there where things are more stable. In this case we seem to have a large
> > number of fairly serious concerns. Do we think the cost of putting this
> > many fixes on develop + the release branch out-weights the benefit of
> less
> > risk of new issues being introduced?
> >
> > Thoughts?
> >
> > Thank you, Sai for taking over!
> >
> > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > sai.boorlaga...@gmail.com>
> > wrote:
> >
> > > I volunteer to be the release manager for 1.9.
> > >
> > > Sai
> > >
> > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann  >
> > > wrote:
> > >
> > > > If there are no other takers, I can act as release manager for 1.9
> and
> > > will
> > > > cut a release branch this week.
> > > >
> > > >
> > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> amurm...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Hi everyone!
> > > > >
> > > > > February 1st is approaching rapidly which means it's almost time to
> > cut
> > > > > the 1.9 release. Who is interested in being the release manager for
> > > 1.9?
> > > > >
> > > > > Thank you!
> > > > >
> > > >
> > >
> >
>

Re: Geode 1.9 Release Manager

[Nabarun Nag]

I agree but not putting in these fixes means that we are releasing with
serious known issues in the product. Hence in my opinion this risk is
acceptable.

Regards
Naba

On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann 
wrote:

> >
> > For the second part, I am not sure how it was determined that fixes for
> > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of
> introducing
> > more failures. Are we lacking tests , reviews  etc. I apologize but I was
> > not able to understand.
> >
> Not sure if you were responding to me. My concern wasn't that these fixes
> introduce a regression, but that other changes happening on develop might
> introduce new issues.
>
> That said, every change always carries some amount of risk to introduce a
> new issue on any codebase, Even 100% test coverage can only make it a lot
> less likely, but not remove the risk entirely.
>
> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag  wrote:
>
> > I could not find any DISCUSS mails about not blocking a release. I may be
> > wrong, I apologize for that but could point me to the mail /
> documentation
> > about the release management.
> >
> > Regards
> > Naba
> >
> > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > sai.boorlaga...@gmail.com>
> > wrote:
> >
> > > Did we not agreed that we won't be blocking a release to include fixes
> as
> > > we are in a fixed release schedule?
> > >
> > >
> > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> amurm...@apache.org>
> > > wrote:
> > >
> > > > Usually I am a proponent of cutting a branch and then fixing things
> on
> > > > there where things are more stable. In this case we seem to have a
> > large
> > > > number of fairly serious concerns. Do we think the cost of putting
> this
> > > > many fixes on develop + the release branch out-weights the benefit of
> > > less
> > > > risk of new issues being introduced?
> > > >
> > > > Thoughts?
> > > >
> > > > Thank you, Sai for taking over!
> > > >
> > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > > sai.boorlaga...@gmail.com>
> > > > wrote:
> > > >
> > > > > I volunteer to be the release manager for 1.9.
> > > > >
> > > > > Sai
> > > > >
> > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > amurm...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > If there are no other takers, I can act as release manager for
> 1.9
> > > and
> > > > > will
> > > > > > cut a release branch this week.
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > > amurm...@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi everyone!
> > > > > > >
> > > > > > > February 1st is approaching rapidly which means it's almost
> time
> > to
> > > > cut
> > > > > > > the 1.9 release. Who is interested in being the release manager
> > for
> > > > > 1.9?
> > > > > > >
> > > > > > > Thank you!
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Geode 1.9 Release Manager

[Nabarun Nag]

Ahhh. Thank you Alexander. That makes sense.

I agree with you, as I mentioned in an earlier email
*I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into the release
branch.*

Regards
Naba

On Thu, Feb 14, 2019 at 1:42 PM Alexander Murmann 
wrote:

> Naba, I agree that we should fix these before releasing. I was talking
> about the trade offs between fixing on develop and then branch or branching
> first and then fixing on develop and release branch.
>
> On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag  wrote:
>
> > I agree but not putting in these fixes means that we are releasing with
> > serious known issues in the product. Hence in my opinion this risk is
> > acceptable.
> >
> > Regards
> > Naba
> >
> > On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann 
> > wrote:
> >
> > > >
> > > > For the second part, I am not sure how it was determined that fixes
> for
> > > > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of
> > > introducing
> > > > more failures. Are we lacking tests , reviews  etc. I apologize but I
> > was
> > > > not able to understand.
> > > >
> > > Not sure if you were responding to me. My concern wasn't that these
> fixes
> > > introduce a regression, but that other changes happening on develop
> might
> > > introduce new issues.
> > >
> > > That said, every change always carries some amount of risk to
> introduce a
> > > new issue on any codebase, Even 100% test coverage can only make it a
> lot
> > > less likely, but not remove the risk entirely.
> > >
> > > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag  wrote:
> > >
> > > > I could not find any DISCUSS mails about not blocking a release. I
> may
> > be
> > > > wrong, I apologize for that but could point me to the mail /
> > > documentation
> > > > about the release management.
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > > > sai.boorlaga...@gmail.com>
> > > > wrote:
> > > >
> > > > > Did we not agreed that we won't be blocking a release to include
> > fixes
> > > as
> > > > > we are in a fixed release schedule?
> > > > >
> > > > >
> > > > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> > > amurm...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Usually I am a proponent of cutting a branch and then fixing
> things
> > > on
> > > > > > there where things are more stable. In this case we seem to have
> a
> > > > large
> > > > > > number of fairly serious concerns. Do we think the cost of
> putting
> > > this
> > > > > > many fixes on develop + the release branch out-weights the
> benefit
> > of
> > > > > less
> > > > > > risk of new issues being introduced?
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Thank you, Sai for taking over!
> > > > > >
> > > > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > > > > sai.boorlaga...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I volunteer to be the release manager for 1.9.
> > > > > > >
> > > > > > > Sai
> > > > > > >
> > > > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > > > amurm...@apache.org
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > If there are no other takers, I can act as release manager
> for
> > > 1.9
> > > > > and
> > > > > > > will
> > > > > > > > cut a release branch this week.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > > > > amurm...@apache.org
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi everyone!
> > > > > > > > >
> > > > > > > > > February 1st is approaching rapidly which means it's almost
> > > time
> > > > to
> > > > > > cut
> > > > > > > > > the 1.9 release. Who is interested in being the release
> > manager
> > > > for
> > > > > > > 1.9?
> > > > > > > > >
> > > > > > > > > Thank you!
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Alexander J. Murmann
> (650) 283-1933
>

Re: [VOTE] Apache Geode 1.9.0 RC4

[Nabarun Nag]

+1

   - Source version on gfsh version matches the git repos.

   - Started locator, server, client and did some put / get operations.

   - Build operations are successful on the source.

   - Signatures verified.


~/Downloads ⌚ 10:30:50
> $ gpg --verify apache-geode-1.9.0-src.tgz.asc apache-geode-1.9.0-src.tgz
> gpg: Signature made Fri Apr 19 11:48:52 2019 PDT
> gpg:using RSA key 468A4800EAFB2498
> gpg: Good signature from "Owen Nichols " [full]
> ~/Downloads ⌚ 10:31:38
> $ gpg --verify apache-geode-1.9.0.tgz.asc apache-geode-1.9.0.tgz
> gpg: Signature made Fri Apr 19 11:51:48 2019 PDT
> gpg:using RSA key 468A4800EAFB2498
> gpg: Good signature from "Owen Nichols " [full]
> ~/Downloads ⌚ 10:32:58
> $ gpg --verify apache-geode-examples-1.9.0.tar.gz.asc
> apache-geode-examples-1.9.0.tar.gz
> gpg: Signature made Fri Apr 19 15:59:05 2019 PDT
> gpg:using RSA key 468A4800EAFB2498
> gpg: Good signature from "Owen Nichols " [full]
> ~/Downloads ⌚ 10:33:15
> $ gpg --verify apache-geode-examples-1.9.0.zip.asc
> apache-geode-examples-1.9.0.zip
> gpg: Signature made Fri Apr 19 15:59:06 2019 PDT
> gpg:using RSA key 468A4800EAFB2498
> gpg: Good signature from "Owen Nichols " [full]
> ~/Downloads ⌚ 10:33:44
> $ gpg --verify apache-geode-native-1.9.0-src.tar.gz.asc
> apache-geode-native-1.9.0-src.tar.gz
> gpg: Signature made Fri Apr 19 16:25:20 2019 PDT
> gpg:using RSA key DB5476815A475574577D442B468A4800EAFB2498
> gpg: Good signature from "Owen Nichols " [full]




   -

Regards
Nabarun Nag

On Wed, Apr 24, 2019 at 8:36 AM Ryan McMahon  wrote:

> +1 Verified signatures, compiled from source, and ran all examples.
>
> Ryan
>
> On Tue, Apr 23, 2019 at 3:44 PM Owen Nichols  wrote:
>
> > +1
> >
> > I used gpg --verify to check all signatures, compiled geode from source,
> > ran all examples, and set up a cluster with 2 locators, 3 servers, a
> simple
> > client and SSL enabled.
> >
> > -Owen
> >
> >
> > > On Apr 23, 2019, at 1:32 PM, Dan Smith  wrote:
> > >
> > > +1
> > >
> > > Looks good to me. I ran the geode-release-check against the repo.
> > >
> > > -Dan
> > >
> > > On Fri, Apr 19, 2019 at 5:00 PM Owen Nichols  > <mailto:onich...@pivotal.io>> wrote:
> > >
> > >> Hello, Geode dev community,
> > >>
> > >>
> > >> This is the fourth release candidate for Apache Geode, version 1.9.0.
> > >>
> > >> Thanks to all the community members for their contributions to this
> > >> release!
> > >>
> > >>
> > >> Please do a review and give your feedback. The deadline is before 3 PM
> > PST
> > >> Wed April 24th, 2019.
> > >>
> > >>
> > >> 1.9.0 resolves 296 issues on Apache Geode JIRA system. Release notes
> > >> can be found at:
> > >>
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > <
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > >
> > >>>
> > >>
> > >>
> > >> Please note that we are voting upon the source tags: rel/v1.9.0.RC4
> > >>
> > >>
> > >> Apache Geode:
> > >>
> > >> https://github.com/apache/geode/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode/tree/rel/v1.9.0.RC4> <
> > >> https://github.com/apache/geode/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode/tree/rel/v1.9.0.RC4>>
> > >>
> > >> Apache Geode examples:
> > >>
> > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4> <
> > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4>>
> > >>
> > >> Apache Geode Native:
> > >>
> > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4> <
> > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 <
> > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4>>
> >

Re: [DISCUSS] Remove exception.getMessage() error handling

[Nabarun Nag]

Looking at the ticket, it looks like it is an improvement request for some
additional information for the end user, can we just do what Kirk and Bruce
suggested. Add some logs to explain what happened. In my opinion, an end
user will be more happy to get some detail information rather than an
exception class name.

Regards
Nabarun Nag

On Tue, May 28, 2019 at 3:08 PM Owen Nichols  wrote:

> This example came from https://issues.apache.org/jira/browse/GEODE-6796
> in which the submitter assumed that Geode was deliberately emitting a
> poorly-worded and confusing error message.
>
> @abaker It sounds like your recommendation for this particular ticket
> would be to resolve as ’Not A Bug’, is that correct?
>
> > On May 28, 2019, at 10:03 AM, Anthony Baker  wrote:
> >
> > In the example you provided, I don’t agree that adding the exception
> class name creates a better user experience.
> >
> > Anthony
> >
> >
> >> On May 25, 2019, at 6:39 PM, Owen Nichols  wrote:
> >>
> >> Here’s an example of a message that was logged before Jack’s change:
> >>
> >> l192.168.99.1: nodename nor servname provided, or not known
> >>
> >> Here’s what it will look like now with .toString() instead of
> .getMessage():
> >>
> >> java.net.UnknownHostException: l192.168.99.1: nodename nor servname
> provided, or not known
> >>
> >>
> >> I cannot think of a single good reason to ever print an exception’s
> message stripped of all context.  As Jack noted, many exceptions don’t even
> have a message; the key information is the class of the exception itself.
> Even if you aren’t catching Exception but rather some very specific
> subclass, code should never make assumptions about the text of an exception
> (see PR#3616 <https://github.com/apache/geode/pull/3616> for a recent
> example).
> >>
> >>
> >> @jinmei There is no built-in method in java to capture the entire
> stacktrace as a string.  Exception::toString() just concatenates the
> exception class name and message (i.e. the first line only of a full
> stacktrace)
> >>
> >>
> >>> On May 24, 2019, at 3:37 PM, Dan Smith  wrote:
> >>>
> >>> I think the right thing to do in those 100+ cases may be different in
> each
> >>> case, a blanket search and replace might not be the best idea.
> >>>
> >>> -Dan
> >>>
> >>>
> >>>
> >>> On Fri, May 24, 2019 at 3:05 PM Jinmei Liao  wrote:
> >>>
> >>>> does exception.toString() print out the entire stack trace? If so, I
> don't
> >>>> think we should use that to replace exception.getMessage().
> >>>>
> >>>> On Fri, May 24, 2019 at 1:18 PM Jack Weissburg  >
> >>>> wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Owen and I investigated a strange error message caused because Geode
> >>>>> previously handled an error exception with exception.getMessage()
> instead
> >>>>> of
> >>>>> exception.toString().
> >>>>>
> >>>>> The issue is that the exception message from exception.getMessage()
> could
> >>>>> be unhelpful or empty. Instead, we should return the whole exception
> via
> >>>>> exception.toString().
> >>>>>
> >>>>> exception.getMessage()is used widely throughout the Geode code base
> (100+
> >>>>> times) and could be prone to cause more issues similar to
> >>>>> https://issues.apache.org/jira/browse/GEODE-6796
> >>>>> I would like to change the remaining instances of
> >>>> exception.getMessage()to
> >>>>> avoid future issues of this variety.
> >>>>>
> >>>>> Thoughts? Comments?
> >>>>>
> >>>>> Best,
> >>>>> Jack Weissburg
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>>
> >>>> Jinmei
> >>>>
> >>
> >
>
>

Re: [DISCUSS] require reviews before merging a PR

[Nabarun Nag]

Hi,

I personally feel the same as how Bruce feels.
 - This will make life harder / inconvenient.
 - One approval from a person who is experienced in that part of code is
more than enough for me.
 - The workload on the Geode developers is already too high, it is unfair
to burden then with more tasks which can be avoided.
 - The commits are well written with proper description, hence anyone who
wants to get familiar with the code can go and read them.
 - Comparing other projects like Kafka, Hadoop, Spark and their closed pull
requests, none of them have 3 approvals.
 - Only project I saw was Kubernetes (not ASF) who need minimum 2 approvals
from experts in the module on which the PR is opened and they have over
2000 contributors.

Personally its a -1 for me as the inconveniences outweigh the benefits of
this task.

Regards
Naba


On Fri, May 31, 2019 at 10:10 AM Jinmei Liao  wrote:

> One reason for lacking reviews in the PR might be that people are
> filtering out notifications from github. I've had this problem for a long
> time before I finally figured out a way to filter out noses "other than"
> the review requested emails. Here is a snapshot of my filter setup.
> Hopefully it will be useful to you:
>
> [image: Screen Shot 2019-05-31 at 10.07.26 AM.png]
>
> On Fri, May 31, 2019 at 10:02 AM Owen Nichols  wrote:
>
>> We chose to make Geode an Apache open source project for a reason.  If we
>> no longer wish to embrace The Apache Way <
>> https://www.apache.org/theapacheway/index.html>, perhaps we should
>> reconsider.
>>
>> If we believe that reviewing each other’s code changes is an onerous
>> burden of no value, we should question why.   The long-term success of
>> Geode depends on sharing of knowledge, not “cowboy coders”.  3 reviews
>> means now 3 other people are more familiar with that part of the code...
>>
>> If apathy is our thing, Apache does allows for “lazy consensus”, but you
>> have to declare that you will be using it, e.g. “This PR fixes
>> GEODE-123456; if no-one objects within three days, I'll assume lazy
>> consensus and merge it."
>>
>> > On May 31, 2019, at 9:05 AM, Alexander Murmann 
>> wrote:
>> >
>> > Jake, Owen is quoting the "VOTES ON CODE MODIFICATION" section from
>> > https://www.apache.org/foundation/voting.html . "code modification" ==
>> > "every PR" is a interpretation that I think would bring the project to a
>> > grinding halt.
>> >
>> > On Fri, May 31, 2019 at 9:01 AM Jacob Barrett 
>> wrote:
>> >
>> >>
>> >>
>> >>> On May 31, 2019, at 8:52 AM, Owen Nichols 
>> wrote:
>> >>>
>> >>> Apache requires 3 reviews for code changes. Docs and typos likely
>> would
>> >> not
>> >>> fall under that heading.
>> >>
>> >> Where is this listed  as a requirement? The link you sent before
>> offered
>> >> guidance on common policies within the organization.
>> >>
>> >>
>>
>>
>
> --
> Cheers
>
> Jinmei
>

Re: [DISCUSS] require reviews before merging a PR

[Nabarun Nag]

Hi,

I agree with Dan, I would like to follow what he has suggested.
Also, I will not mind anyone following the 3 reviewers for everything if
they chose to do so. Just please don't make it blanket rule.

Regards
Naba

PS: I found this filter on github to look up PRs that I have reviewed till
date / awaiting reviews.

Reviewed : is:pr is:closed reviewed-by:
Awaiting review : is:pr is:closed review-requested:

On Fri, May 31, 2019 at 11:57 AM Udo Kohlmeyer  wrote:

> Thank you Dan,
>
> Some guidance around how we can go about reviewing the code.
>
> I want to remind ALL
> committers..
> https://www.apache.org/dev/new-committers-guide.html#committer-responsibilities
>
> It states "/Each committer has a responsibility to monitor the changes
> made for potential issues, both coding and legal."/
>
> I cannot see a reason to have any reviewers on trivial (spelling, typos).
>
> Post that, everything should have at least a view reviewers. 1 does not
> an opinion (or reviewed code) make, and I must agree with the statement
> that Owen made. 3 reviewers.
>
> Yes it is a real pita. As it takes dedication from ppl to review code
> and it takes away from our daily lives and the limited time we have to
> dedicate to it. Yet, I cannot understand how out of 70 committers (I'm
> using 70% fudge factor) we cannot get 3 reviews on correctness, style,
> potential bugs. In addition committers CAN nominate reviewers on PR's.
> In addition to the nomination of reviewers, I would advocate that
> reviewers of code not be more than 66% of a potentially biased team
> members. (given that I know many committers are employed by the same
> company).
>
> @Naba I agree, there is more work now. I now as a committer actually
> have to review the code of a fellow committer. BUT we all know that the
> space and code we work on is complex. Concurrent, distributed systems
> are not easy and being too close to the problem could cause blinders to
> issues which someone more removed could spot. The opposite is also true,
> too removed will only evaluate on basic criteria and might not spot
> issues. Regardless of this, we have many troops that can do work.. and 1
> code review 1-2 twice a week is not going to kill us.
>
> I would also like to request of everyone, that when submitting a PR,
> keep an eye on it. Track it, ping the @dev channel if no progress is
> made. Oversights can happen and in some cases emails can be filtered out
> with new PR's or comments made on one's own PR.
>
> --Udo
>
> On 5/31/19 11:33, Dan Smith wrote:
> > As others pointed out - I think it's really important to remember that
> > people and community are much more important than process. That is a key
> > part of "The Apache Way" - it's not a set very specific rules, but more
> of
> > a philosophy of building an open community. I think this page has a good
> > take on the apache way - http://theapacheway.com/.
> >
> > The page I linked also mentions "Getting good enough consensus is often
> > better than voting." Apache is about consensus building, *not* about
> > voting. Ideally, the only things we should formally vote on are
> > irreversible decisions such as a release or new committer.
> >
> > Regarding code reviews, I think having a really strict process implies
> that
> > we don't trust our committers. Rather than that, maybe have some
> guidelines
> > for committers who aren't sure how much of a review to get. Here's what I
> > feel like I've been trying to follow:
> > 1. Fixing a typo, broken spotless, etc. - just push it!
> > 2. Straightforward change - get at least one reviewer. Maybe a second
> > author on the commit should count here?
> > 3. Technically challenging, complicated change - get multiple reviewers
> > 4. New Public API, large features - Write up a wiki page and have a
> > discussion on the dev list to get feedback
> >
> > For all of these, if someone rejects your PR/feature, fix the issues or
> > talk with them. A good rule of thumb is if you are frustrated or annoyed
> by
> > what they said - talk to them one-on-one first instead of answering
> > directly in the PR/thread. If you a really pissed, wait a day and then
> talk
> > to them one-on-one.
> >
> > -Dan
> >
> > On Fri, May 31, 2019 at 11:00 AM Helena Bales  wrote:
> >
> >> Thanks for the filter, Jinmei!
> >>
> >> +1 to Naba and Bruce.
> >>
> >> I will add that I think we should have a formal policy of getting *a*
> >> review (and more for large changes), and that PRs that are merged
> without
> >> one should include (in the PR) a comment providing a justification for
> this
> >> merge, so that committers can review the reasoning later on if needed.
> This
> >> has the benefits of being low impact on our current workflow, but also
> >> increasing transparency, accountability, and thoughtfulness around the
> >> proposed changes and their impact.
> >>
> >> On Fri, May 31, 2019 at 10:42 AM Jinmei Liao  wrote:
> >>
> >>> I was told that screenshot that I sent earlier got filtered out by the
> >>

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

[Nabarun Nag]

In my opinion, I am okay will multiple commits within a PR.
But please do squash them to a single  commit when it is pushed to develop.
This helps us a ton if it is single commit.
- bisect operations are easier when it is a single commit during major
failure analysis.
- cherrypick is easier when it is one commit.


I even don’t prefer merge commit messages :
 -  none of the big ASF projects do it.
 -  visualizing on tools is bit skewed.
 -  difficult to analyze failures .


I would like to reiterate Dan’s statement on emphasis on people and empathy
over blanket process and rules.

Regards
Naba



On Fri, May 31, 2019 at 1:32 PM Helena Bales  wrote:

> +1. I would guess that it is the checklist as part of the PR that is
> confusing people.
>
> The other reason that history gets rewritten is when force pushing after a
> rebase. While fast-forwarding is necessary on occasion, this can be
> accomplished without rewriting history by using a merge.
>
> As part of our document on making PRs, we should include instructions on
> how to handle the situation where fast-forwarding is necessary, explicitly
> discourage the use of merges and force-pushes once a PR has been opened,
> and some guidelines regarding the appropriate number of commits when the PR
> is initially opened. Once we have these guidelines, it would be helpful to
> link to them from the PR checklist that we currently have, and rework the
> checklist so that it is in line with our desired process.
>
> On Fri, May 31, 2019 at 1:20 PM Darrel Schneider 
> wrote:
>
> > Something I have noticed is that often when I have requested changes be
> > made to a pull request is that the changes are force pushed ask a single
> > commit to the pr. I would actually prefer that the changes show up as a
> new
> > commit on the pr instead of everything being rebased into one commit.
> That
> > makes the history of the pr easier to follow and make it easy to see what
> > has changed since the previous review. What do others think? Have we done
> > something that makes contributors think the pull request has to be single
> > commit? I know the initial pull request is supposed to be but from then
> on
> > I'd prefer that we wait to squash when we merge it to develop.
> >
>

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

[Nabarun Nag]

>
> This sounds to me like "all my friends are jumping off bridges" and an
> incorrect application or understanding of your toolset.  In my own
> experience, I have had much more trouble trying to track a bug through
> massive squashed commits than I have identifying which branch was
> responsible for a code change.


-> learning from long standing successful Apache projects is not equivalent
of  "all my friends are jumping off bridges". You need to re-think that.
This is what is done because it is convenient and makes our lives easier,
and this is a sentiment shared by a lot of developers.


This might just be a bit of philosophy, but I have to disagree with you.


Sure, but in practice things are easier the other way.


@Udo : I agree.

Regards
Naba





On Fri, May 31, 2019 at 2:23 PM Udo Kohlmeyer  wrote:

> I think a single (squashed if required) commit for the start of a PR.
> ANY changes due to comments should be reflected as separate commits on
> the PR.
> Once approved, that PR should squash all commits into 1 commit with a
> message that describes what was done,etc...
>
> In the past I've heard developers ask for the following:
>
> 1x commit to address the problem/feature
> 1x commit with refactors.
>
> I must be honest, but I am yet to find 1 developer that keeps a list of
> all changes they want to be refactored separate from the bug/feature
> code. OR better stated I am yet to find where this was sustainable AND
> productive.
>
> It would definitely discourage the community to refactor, because who
> keeps track of all the code they would like to refactor and change the
> code after completing the task. Sounds like double if not triple work to
> me.
>
> Also, how would this work if there are comments on the code i.e better
> approaches, have you thought about... or that might lead to errors. Are
> these changes applied to the core/base commit or against the refactor or
> both?
>
> Also, a good practice for all is to commit (and push) code on a daily
> basis on their branches. "WIP - completed x,y,z. need to address: a,g,r"
> comments are not uncommon and safeguard against loss of equipment,
> illness of members,etc...
>
> My personal coding style is, I make changes to code as I pass through
> it.. (change variable names when they don't make sense, refactor
> methods, etc...) So, I rarely have the time to retrace my steps and
> post-factum re-apply my refactored changes.
>
> I think the checklist could be reworded, but as everything in this
> project, we take it in the spirit was intended and don't follow it to
> the letter. Would the rewording of the checklist enhance/improve/make
> the intent clearer or not? I don't care either way, but when someone
> merges a PR into a main branch with many intermediate commits, it just
> clusters the commit log with "contextually irrelevant" noise. (also
> makes it harder to follow all the changes that are in a branch). What if
> I want to rollback a commit into develop, how many does one have to
> revert, 1 is always simpler than 2-10... Also.. cherry picking becomes
> simpler...
>
> --Udo
>
> On 5/31/19 13:43, Nabarun Nag wrote:
> > In my opinion, I am okay will multiple commits within a PR.
> > But please do squash them to a single  commit when it is pushed to
> develop.
> > This helps us a ton if it is single commit.
> > - bisect operations are easier when it is a single commit during major
> > failure analysis.
> > - cherrypick is easier when it is one commit.
> >
> >
> > I even don’t prefer merge commit messages :
> >   -  none of the big ASF projects do it.
> >   -  visualizing on tools is bit skewed.
> >   -  difficult to analyze failures .
> >
> >
> > I would like to reiterate Dan’s statement on emphasis on people and
> empathy
> > over blanket process and rules.
> >
> > Regards
> > Naba
> >
> >
> >
> > On Fri, May 31, 2019 at 1:32 PM Helena Bales  wrote:
> >
> >> +1. I would guess that it is the checklist as part of the PR that is
> >> confusing people.
> >>
> >> The other reason that history gets rewritten is when force pushing
> after a
> >> rebase. While fast-forwarding is necessary on occasion, this can be
> >> accomplished without rewriting history by using a merge.
> >>
> >> As part of our document on making PRs, we should include instructions on
> >> how to handle the situation where fast-forwarding is necessary,
> explicitly
> >> discourage the use of merges and force-pushes once a PR has been opened,
> >> and some guidelines regarding the appropriate number of

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi,
I believe the original authors of the feature has done their due diligence
and followed all steps, we can get this feature in under the Experimental
flag and let the community improve on it, if there is anything else that
needs to be done.

We have done this before for Lucene re-index feature, where we involved the
entire community in its development, phase by phase. The wiki is up and
running, if someone has any concerns can raise it as a JIRA or comment in
the wiki and the community as a whole can decide if it is a valid
concern or not and act upon it.

Regards
Nabarun Nag



On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer  wrote:

> @Alexander + @Jared,
>
> So maybe that was my misunderstanding on the RFC (not being optional on
> new feature work). Given that this is a new feature, there is
> significant risk to getting it "wrong".
>
> I was expecting more discussion around this. I have some objections to
> the current approach/design. Given that my day job does not allow me to
> respond in a timely manner, I would have not been able to get all my
> concerns raised. In addition, throwing something onto the wiki, and then
> a few weeks before we'd like to cut a version raising a discussion
> thread on work that has been going on for months already does not help
> with the community being able to read, digest, think, reason and respond
> BEFORE it is released.
>
> I know `@Experimental` is non-binding on API's or usage, BUT I prefer
> some of the ground work to have been discussed, API's validated BEFORE
> it is released into the wild. I mean this is a PUBLIC API, so we'd
> prefer to get it more correct than the previous one.
>
> Maybe it is just me, taking it too serious... Where I prefer not release
> something as close to 95% correct (and discussed).
>
> Anyway.. If we want to cut 1.10... and we should... Let's do so.. but
> I'd prefer that more on the correctness on the approach.
>
> --Udo
>
> On 7/25/19 11:08 AM, Alexander Murmann wrote:
> >> I don't believe we should be including anything into the Geode release
> >> that has not gone through the correct process of feature proposal.
> >>
> >> All work under the experimental cluster management service has not yet
> >> been approved by the agreed upon RFC process.
> >>
> > Udo, I didn't take the RFC process that we agreed on to be a gate keeper,
> > but rather a way to de-risk work before making a PR.
> >
> >  From the RFC doc in the wiki:
> >
> >> When to write an RFC?
> >>
> >> Writing an RFC should be entirely voluntary. There is always the option
> of
> >> going straight to a pull request. However, for larger changes, it might
> be
> >> wise to de-risk the risk of rejection of the pull request by first
> >> gathering input from the community. Therefore it’s up to every member of
> >> our community to decide themselves when they want to reach for this
> tool.
> >>
> > If we want to change the role of the RFC process, that's fine with me,
> but
> > we should have that discussion first.
> >
> > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart 
> > wrote:
> >
> >> What was missing from the RFC process for the cluster management
> service?
> >> I saw a [Discuss] thread for it, as well as a proposal at
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> >>
> >> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer  wrote:
> >>
> >>> I don't believe we should be including anything into the Geode release
> >>> that has not gone through the correct process of feature proposal.
> >>>
> >>> All work under the experimental cluster management service has not yet
> >>> been approved by the agreed upon RFC process.
> >>>
> >>> I don't believe we should be including this work, experimental or
> >>> otherwise.
> >>>
> >>> --Udo
> >>>
> >>> On 7/22/19 4:51 PM, Alexander Murmann wrote:
> >>>> Udo, do you mind explaining how the RFC process comes into this? Are
> >> you
> >>>> suggesting that we should wait if an RFC had a target release
> attached?
> >>>>
> >>>> On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:
> >>>>
> >>>>> I don't think we need to wait for this, as there has been no RFC
> >> process
> >>>>> followed.
> >>>>>
> >>>>> --Udo
> >>>>>
> >>>>> On 7/

Re: New release branch for Apache Geode 1.10.0

[Nabarun Nag]

Hi,

We believe that the current release branch has an issue of getting a
NullPointerException when we try calling LocalRegion.getLocalSize when the
region is in the process of being initialized. The fix for this issue is
very critical and we should re-create the branch when the fix is placed in
develop.
We need to hold any pipeline testing on the branch till this fix is in.

Regards
Nabarun Nag

On Fri, Aug 2, 2019 at 11:17 AM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> We have created a new release branch for Apache Geode 1.10.0 -
> "release/1.10.0"
>
> Please do review and raise any concern with the release branch. If no
> concerns are raised, we will start with the voting for the release
> candidate soon.
>
> Regards
>
> Dick Cavender
> Apache Geode 1.10.0 Release Manager
>

Re: New release branch for Apache Geode 1.10.0

[Nabarun Nag]

Thank you  Aaron and Kirk for getting the fix in.

Regards
Naba


On Fri, Aug 2, 2019 at 5:25 PM Aaron Lindsey  wrote:

> +1 to including this PR in the 1.10.0 release.
>
> Just to elaborate on the issue: If the stats sampler calls
> LocalRegion.getLocalSize before that region is initialized, it will throw a
> NullPointerException. This can happen because we have escaping references
> to “this” in the LocalRegion constructor that allow the stats sampler to
> call getLocalSize before the LocalRegion object is fully constructed.
>
> - Aaron
>
> > On Aug 2, 2019, at 5:21 PM, Michael Oleske  wrote:
> >
> > Naba's concern was this PR: https://github.com/apache/geode/pull/3880
> which
> > has been merged to develop
> >
> > -michael
> >
> > On Fri, Aug 2, 2019 at 4:33 PM Owen Nichols  wrote:
> >
> >> Hi Naba, thank you for bringing your concern.
> >>
> >> Our current process <
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >
> >> dictates a time-based schedule to cut release branches.  Once cut, the
> >> “critical fixes” rule allows critical fixes to be brought to the release
> >> branch by proposal on the dev list.
> >>
> >> Currently the 1.10.0 release pipeline <
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main
> >
> >> is all green.  Perhaps one way to convince the Geode community that your
> >> fix satisfies the “critical fixes” rule might be to share a link to a
> >> github commit adding tests that expose the issue.
> >>
> >> Thanks,
> >> -Owen
> >>
> >>
> >>> On Aug 2, 2019, at 12:55 PM, Nabarun Nag  wrote:
> >>>
> >>> Hi,
> >>>
> >>> We believe that the current release branch has an issue of getting a
> >>> NullPointerException when we try calling LocalRegion.getLocalSize when
> >> the
> >>> region is in the process of being initialized. The fix for this issue
> is
> >>> very critical and we should re-create the branch when the fix is placed
> >> in
> >>> develop.
> >>> We need to hold any pipeline testing on the branch till this fix is in.
> >>>
> >>> Regards
> >>> Nabarun Nag
> >>>
> >>> On Fri, Aug 2, 2019 at 11:17 AM Dick Cavender 
> wrote:
> >>>
> >>>> Hello Geode Dev Community,
> >>>>
> >>>> We have created a new release branch for Apache Geode 1.10.0 -
> >>>> "release/1.10.0"
> >>>>
> >>>> Please do review and raise any concern with the release branch. If no
> >>>> concerns are raised, we will start with the voting for the release
> >>>> candidate soon.
> >>>>
> >>>> Regards
> >>>>
> >>>> Dick Cavender
> >>>> Apache Geode 1.10.0 Release Manager
> >>>>
> >>
> >>
>
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

he earliest
> >>>>>>>> releases of Geode.  The commit occurred after SHA1
> >>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> >>>>>>>> Thanks.  Karen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender 
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I'll take on the Release Manager role for Geode 1.10 with the
> >> 1.9.0
> >>>>>>>> release
> >>>>>>>>> manager's help (Owen:).
> >>>>>>>>>
> >>>>>>>>> I'd like to propose cutting the release/1.10 branch off develop
> >> sha:
> >>>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> >>>>>>>>>
> >>>>>>>>> aka: 1.10.0-SNAPSHOT.476
> >>>>>>>>>
> >>>>>>>>> Please speak up and discuss. We'll then start taking
> >> considerations
> >>>>> for
> >>>>>>>>> additional changes for 1.1.0 after we get the branch and pipeline
> >> in
> >>>>>>>> place.
> >>>>>>>>>
> >>>>>>>>> -Dick
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <
> >>>>> amurm...@apache.org
> >>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for calling this out Ernie!
> >>>>>>>>>>
> >>>>>>>>>> It might be a good idea to cut the release and at the same time
> >>> keep
> >>>>>>>>>> looking for urgent issues that need to be resolved and merged.
> >> Once
> >>>>>> the
> >>>>>>>>>> branch is cut, we release likelihood of new issues being
> >>> introduced.
> >>>>>>>>>>
> >>>>>>>>>> Does anyone know of any other issues, we'd want to make sure get
> >>>>>>>>> addressed
> >>>>>>>>>> before we ship?
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
> >>>>>>>> eburgha...@pivotal.io>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> There is a PR #3844 <https://github.com/apache/geode/pull/3844
> >
> >>> up
> >>>>>>>> to
> >>>>>>>>>>> address GEODE-7012 <
> >>>>> https://issues.apache.org/jira/browse/GEODE-7012
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>>> think this should be in the next release...
> >>>>>>>>>>>
> >>>>>>>>>>> EB
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
> >>>>>>>> amurm...@apache.org
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> *Cutting the release*
> >>>>>>>>>>>> Do we have any volunteers to take over the release manager
> >> role?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *Re: Udo's concerns*
> >>>>>>>>>>>> While I believe that iterations of this particular work have
> >> been
> >>>>>>>>>>> discussed
> >>>>>>>>>>>> on the mailing list as far back as March 2018, I do think that
> >> we
> >>>>>>>>>> should
> >>>>>>>>>>>> take Udo's response as an indicator that something with our
> >>> larger
> >>>>>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi Geode Community,

After some further analysis, few of the threads are hanging in our
application using the release branch. Here is an example stacktrace.
*** Hung thread
"vm_5_thr_5_client1_host1_21862" #457 daemon prio=5 os_prio=0
tid=0x7fc204009800 nid=0x69aa waiting on condition
[0x7fc1de195000]
   java.lang.Thread.State: TIMED_WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0xf10d8098> (a
java.util.concurrent.CountDownLatch$Sync)
  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
  at 
org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
  at 
org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.waitForCacheOrFunctionException(FunctionStreamingResultCollector.java:439)
  at 
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:90)

We did some further investigation and we presume that it was introduced by
the following commit.
GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r…
(#3853)

We are planning to revert this commit in the release branch as this is a
necessary fix that needs to be in the release.

Regards
Nabarun Nag



On Tue, Aug 6, 2019 at 1:39 PM Bruce Schuchardt 
wrote:

> +1
>
> On 8/6/19 1:33 PM, Nabarun Nag wrote:
> > +1 on getting the Fix [Upgrade
> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> > in the geode-core pom.] in.
> >
> >
> > Spring Data for Apache Geode has been removed from Spring Initializr
> > because of the issue with  log4j dependencies, also IntelliJ doesn't list
> > it as a NoSQL dependency. I would prefer that it is resolved in this
> > release and not wait for 3-4 months.
> >
> > Regards
> > Naba
> >
> >
> >
> > On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols  wrote:
> >
> >> Hi Kirk, thank you for bringing your concern.
> >>
> >> Yes, release/1.10.0 was created last week <
> >>
> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E
> >
> >> as planned.  Our current process <
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >
> >> dictates a time-based schedule to cut release branches.  Once cut, the
> >> “critical fixes” rule allows critical fixes to be brought to the release
> >> branch by proposal on the dev list.
> >>
> >> Currently the 1.10.0 release pipeline <
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main
> >
> >> is all green.  If there is consensus from the Geode community that this
> >> log4j change satisfies the “critical fixes” rule, Dick or I will be
> happy
> >> to bring it to the 1.10.0 release branch.
> >>
> >> -Owen
> >>
> >>> On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
> >>>
> >>> Did we already cut the 1.10 branch?
> >>>
> >>> I'd like to find out if it's possible to get a change into 1.10:
> Upgrade
> >>> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional
> dependency
> >>> in the geode-core pom.
> >>>
> >>> Getting this change into 1.10 will make things much easier for Spring
> >> Boot
> >>> Data Geode. When using Geode with Spring Boot, log4j-core has to be
> >>> manually excluded so that logback can be used instead. The change to
> >> log4j
> >>> 2.12.0 will also help as they have already have some dependency on
> 2.12.0
> >>> (probably log4j-to-slf4j). I can find out more precise details if
> needed.
> >>>
> >>> On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender 
> wrote

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi,

The commit mentioned in the earlier email has now been reverted on develop
and release/1.10.0 branches.
Thank you for your patience.

Regards
Nabarun Nag


On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag  wrote:

> Hi Geode Community,
>
> After some further analysis, few of the threads are hanging in our
> application using the release branch. Here is an example stacktrace.
> *** Hung thread
>
> "vm_5_thr_5_client1_host1_21862" #457 daemon prio=5 os_prio=0 
> tid=0x7fc204009800 nid=0x69aa waiting on condition [0x7fc1de195000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>
>   - parking to wait for  <0xf10d8098> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
>
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
>
>   at 
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
>
>   at 
> org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.waitForCacheOrFunctionException(FunctionStreamingResultCollector.java:439)
>
>   at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:90)
>
> We did some further investigation and we presume that it was introduced by
> the following commit.
> GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r…
> (#3853)
>
> We are planning to revert this commit in the release branch as this is a
> necessary fix that needs to be in the release.
>
> Regards
> Nabarun Nag
>
>
>
> On Tue, Aug 6, 2019 at 1:39 PM Bruce Schuchardt 
> wrote:
>
>> +1
>>
>> On 8/6/19 1:33 PM, Nabarun Nag wrote:
>> > +1 on getting the Fix [Upgrade
>> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional
>> dependency
>> > in the geode-core pom.] in.
>> >
>> >
>> > Spring Data for Apache Geode has been removed from Spring Initializr
>> > because of the issue with  log4j dependencies, also IntelliJ doesn't
>> list
>> > it as a NoSQL dependency. I would prefer that it is resolved in this
>> > release and not wait for 3-4 months.
>> >
>> > Regards
>> > Naba
>> >
>> >
>> >
>> > On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols 
>> wrote:
>> >
>> >> Hi Kirk, thank you for bringing your concern.
>> >>
>> >> Yes, release/1.10.0 was created last week <
>> >>
>> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E
>> >
>> >> as planned.  Our current process <
>> >>
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>> >
>> >> dictates a time-based schedule to cut release branches.  Once cut, the
>> >> “critical fixes” rule allows critical fixes to be brought to the
>> release
>> >> branch by proposal on the dev list.
>> >>
>> >> Currently the 1.10.0 release pipeline <
>> >>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main
>> >
>> >> is all green.  If there is consensus from the Geode community that this
>> >> log4j change satisfies the “critical fixes” rule, Dick or I will be
>> happy
>> >> to bring it to the 1.10.0 release branch.
>> >>
>> >> -Owen
>> >>
>> >>> On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
>> >>>
>> >>> Did we already cut the 1.10 branch?
>> >>>
>> >>> I'd like to find out if it's possible to get a change into 1.10:
>> Upgrade
>

Re: Proposal to Include GEODE-7079 in 1.10.0

[Nabarun Nag]

+1

On Thu, Aug 15, 2019 at 10:15 AM Alexander Murmann 
wrote:

> +1
>
> Agreed to fixing this. It's impossible for a user to discover they hit an
> edge case that we fail to support till they are in prod and restart.
>
> On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos 
> wrote:
>
> > Hello Udo,
> >
> > Even if it is an existing issue I'd still consider it critical for those
> > cases on which there are unprocessed events on the persistent queue
> after a
> > restart and the region takes long to recover... you can actually see
> > millions of *NPEs* flooding the member's logs.
> > My two cents anyway, it's up to the community to make the final decision.
> > Cheers.
> >
> >
> > On Thu, Aug 15, 2019 at 5:58 PM Udo Kohlmeyer  wrote:
> >
> > > Juan,
> > >
> > >  From your explanation, it seems this issue is existing and not
> > > critical. Could we possibly hold this for 1.11?
> > >
> > > --Udo
> > >
> > > On 8/15/19 5:29 AM, Ju@N wrote:
> > > > Hello team,
> > > >
> > > > I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in
> > > release
> > > > 1.10.0.
> > > > Long story short: a *NullPointerException* can be continuously thrown
> > > > and flood the member's logs if a serial event processor (either
> > > > *async-event-queue* or *gateway-sender*) starts processing events
> from
> > a
> > > > recovered persistent queue before the actual region to which it was
> > > > attached is fully operational.
> > > > Note: *no events are lost (even without the fix)* but, if the region
> > > takes
> > > > a while to recover, the logs  for the member can grow pretty quickly
> > due
> > > to
> > > > the continuously thrown *NPEs.*
> > > > Best regards.
> > > >
> > > > [1]:
> > > >
> > >
> >
> https://github.com/apache/geode/commit/6f4bbbd96bcecdb82cf7753ce1dae9fa6baebf9b
> > > > [2]: https://issues.apache.org/jira/browse/GEODE-7079
> > > >
> > >
> >
> >
> > --
> > Juan José Ramos Cassella
> > Senior Software Engineer
> > Email: jra...@pivotal.io
> >
>

Re: Propose fix for 1.10 release: Export offline data command failed with EntryDestroyedException

[Nabarun Nag]

+1

On Fri, Aug 16, 2019 at 2:45 PM Anilkumar Gingade 
wrote:

> +1 to include
>
> On Fri, Aug 16, 2019 at 2:41 PM Anthony Baker  wrote:
>
> > +1 from me.  When you need to do an offline export, it’s usually
> > important.  Not being able to export *all* the data might lead to data
> loss.
> >
> > Anthony
> >
> >
> > > On Aug 16, 2019, at 2:06 PM, Udo Kohlmeyer  wrote:
> > >
> > > +1 to include
> > >
> > >
> > > On 8/16/19 12:43 PM, Eric Shu wrote:
> > >> Hi,
> > >>
> > >> I'd like to include the following commit (
> > >> https://gitbox.apache.org/repos/asf?p=geode.git;h=aa33060) into Geode
> > 1.10
> > >> release.
> > >>
> > >> The commit fixes the issue that a user tries to use export offline
> data
> > to
> > >> a snapshot file but failed. This issue exists from release 1.1.0.
> > However,
> > >> it is a critical issue, as it prevents users to get the data from
> their
> > >> backup disk stores.
> > >>
> > >> Regards,
> > >> Eric
> > >>
> >
> >
>

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

[Nabarun Nag]

Hi Anil,

Will it be possible to explain to the community how the starting AEQ in a
paused state is different from creating gateway senders with manual start
set to true. It may be of concern as  'manual start'  for gateways is a
deprecated.

Just thinking out loud, will it be more feasible if we can set the flag at
cache level. Any framework that is starting up Apache Geode (E.g: Spring) ,
creates the cache -> cache.pauseProcessing(); -> create regions -> create
AEQs -> cache.unpauseProcessing()

We can gate the processing of all event listener at dispatchBatch().

The advantage I feel is that
 - we avoid introducing a new API to the AEQ creation factory.
 - if we created 100 AEQs in paused state then we avoid having to have 100
AEQ.unpause calls.


Regards
Naba


On Tue, Aug 20, 2019 at 9:07 AM Michael Stolz  wrote:

> Manual start has caused a lot of trouble over the years. We should
> definitely circle back on those issues before traveling very far down this
> road.
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
>
>
> On Tue, Aug 20, 2019 at 11:56 AM Juan José Ramos 
> wrote:
>
> > Hello Anil,
> >
> > +1 for the proposed solution.
> > I'd change the method name from *pauseEventDispatchToListener* to
> something
> > more meaningful and understandable for our users, maybe *startPaused*?,
> > *setManualStart* (as we currently have for the *GatewaySenderFactory*)?,
> > *startWithEventDispatcherPaused*?.
> > Best regards.
> >
> >
> >
> > On Sat, Aug 17, 2019 at 12:55 AM Anilkumar Gingade 
> > wrote:
> >
> > > I have updated the wiki based on Dan's comment.
> > > Changes with api:
> > >
> > > *On "AsyncEventQueueFactory" interface - *
> > >
> > > *AsyncEventQueueFactory pauseEventDispatchToListener();  *// This
> causes
> > > AEQ to be created with paused state.
> > >
> > >
> > >
> > >
> > > On Fri, Aug 16, 2019 at 4:36 PM Anilkumar Gingade  >
> > > wrote:
> > >
> > > > Dan,
> > > >
> > > > If you look into the API; the AEQ will be created with the pause
> state.
> > > > The user (application) has to call resume to dispatch the events.
> > > >
> > > > It will be slightly different from GatewaySender behavior; where
> > > > GatewaySender will be created with run mode and then application has
> to
> > > > call pause on it. Here in this case AEQ will be created with paused
> > > state.
> > > >
> > > > -Anil.
> > > >
> > > >
> > > > On Fri, Aug 16, 2019 at 4:31 PM Dan Smith  wrote:
> > > >
> > > >> Hi Anil,
> > > >>
> > > >> While I like the idea of matching the API of GatewaySender, I'm not
> > > sure I
> > > >> see how this solves the problem. Is it required of the user to call
> > > pause
> > > >> on the AsyncEventQueue as soon as it is created? How would someone
> do
> > > that
> > > >> when creating AEQs with xml or cluster configuration? Maybe it would
> > be
> > > >> better to not dispatch any events until we are done creating all
> > > regions?
> > > >>
> > > >> -Dan
> > > >>
> > > >> On Fri, Aug 16, 2019 at 2:31 PM Anilkumar Gingade <
> > aging...@pivotal.io>
> > > >> wrote:
> > > >>
> > > >> > Proposal to support controlling capability with event dispatch to
> > > >> > AsyncEventQueue Listener.
> > > >> >
> > > >> > Wiki proposal page:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Controlling+event+dispatch+to+AsyncEventListener
> > > >> >
> > > >> > Here is the details from the wiki page:
> > > >> > *Problem*
> > > >> >
> > > >> > *The Geode system requires AEQs to be configured before regions
> are
> > > >> > created. If an AEQ listener is operating on a secondary region,
> this
> > > >> could
> > > >> > cause listener to operate on a region which is not yet created or
> > > fully
> > > >> > initialized (for region with co-located regions) which could
> result
> > in
> > > >> > missing events or dead-lock scenario between region (co-located
> > > region)
> > > >> > creation threads. This scenario is likely to happen during
> > persistence
> > > >> > recovery; when AEQs are created in the start, the recovered AEQ
> > events
> > > >> are
> > > >> > dispatched immediately, thus invoking the AEQ listeners.*
> > > >> > Anti-Goals
> > > >> >
> > > >> > None
> > > >> > *Solution*
> > > >> >
> > > >> > *The proposed solution is to provide a way to control dispatching
> > AEQ
> > > >> > events to the AEQ Listeners, this could be done by adding "pause"
> > and
> > > >> > "resume" capability to the AEQ, which will allow application to
> > decide
> > > >> when
> > > >> > to dispatch events to the listeners. *
> > > >> >
> > > >> >
> > > >> > *The proposal is similar to existing "pause" and "resume" behavior
> > on
> > > >> the
> > > >> > GatewaySender, on which the AEQ is based on (AEQ implementation
> is a
> > > >> > wrapper around GatewaySender). *
> > > >> > Changes and Additions to Public Interfaces
> > > >> >
> > > >> > *The proposed APIs are:*
> > > >> >
> > > >> > *On "AsyncEventQueueFactory" interface - 

Re: Proposal to include GEODE-7088 and GEODE-7089 in 1.10.0

[Nabarun Nag]

+1

This will be a good inclusion in Apache Geode 1.10.0 release.

Regards
Naba

On Mon, Aug 26, 2019 at 3:36 PM Jacob Barrett  wrote:

> +1
>
> Thanks for the details!
>
> > On Aug 26, 2019, at 3:33 PM, Ryan McMahon  wrote:
> >
> > Udo,
> >
> > Here are inline answers to your questions:
> >
> > *Is this an existing issue?*
> >
> > Short answer - yes, but it has never been in a release version of Geode.
> > The leak was introduced as part of some changes to address handling
> > multiple concurrent registration requests for a given client on a single
> > server.  The issue is only seen if client registration fails which is not
> > particularly common, which is why we are only seeing it now after months
> of
> > testing.  The commit for that was introduced here on April 30th.
> >
> https://github.com/apache/geode/commit/bc2a2fa5af374cfedfba4dc1abe6cbc2a7b719c8
> > The ConcurrentModificationException issue (which ultimately causes the
> > registration to fail) was introduced on April 22nd here:
> >
> https://github.com/apache/geode/commit/afc311c04f6908a8f725834cdf2c49ce6e902b3f
> >
> >
> > *Why is it more critical to squeeze it into an existing (almost
> > release) version of Apache Geode?*
> >
> > Not sure I totally understand this question, but it is critical because
> the
> > leak can cause servers to crash due to OOM.  Again, because the problems
> > were introduced in late April and we haven't released Geode since then,
> so
> > I think it is very important to merge these fixes into 1.10.0 before we
> > release.
> >
> >
> >
> > *What guarantees do we have that this fix makes the application more
> stable
> > compared to adding another hidden issue, which we will discover in
> another
> > few weeks from now?*
> >
> > I added numerous tests for this scenario to ensure that the leak would
> > never happen regardless of the cause of a failed client registration.
> > There obviously is no way to 100% guarantee that there will be no issues
> > that arise from the fixes themselves, but our existing test coverage plus
> > the new tests I wrote should give us the confidence we need.
> >
> > Thanks,
> > Ryan
> >
> > On Mon, Aug 26, 2019 at 3:17 PM Udo Kohlmeyer  wrote:
> >
> >> In order to better understand this request:
> >>
> >> Is this an existing issue?
> >>
> >> Why is it more critical to squeeze it into an existing (almost release)
> >> version of Apache Geode?
> >>
> >> What guarantees do we have that this fix makes the application more
> >> stable compared to adding another hidden issue, which we will discover
> >> in another few weeks from now?
> >>
> >>
> >> --Udo
> >>
> >> On 8/26/19 3:10 PM, Ryan McMahon wrote:
> >>> Hi all,
> >>>
> >>> I would like to propose cherry-picking GEODE-7088 and GEODE-7089 to the
> >>> 1.10.0 release branch.  The two JIRAs are related to the same root
> >> problem,
> >>> which I would classify as critical.  We discovered a case where a
> failed
> >>> client registration could lead to a memory leak in a server, eventually
> >>> causing the server to crash due to lack of memory.
> >>>
> >>> The issue is instigated by a ConcurrentModificationException due to
> >>> iteration of a non-thread safe collection while it is being mutated
> >>> (GEODE-7088).  This exception occurs when the client's queue image is
> >> being
> >>> copied from one server to the next during client registration, and it
> >>> causes the client's registration to fail.  The client would likely
> >> succeed
> >>> if it retried registration with that same server, but if it registers
> >> with
> >>> a different server, we end up leaking events to the client's
> registration
> >>> queue on the original server (GEODE-7089).
> >>>
> >>> The fix for GEODE-7088 is to use thread-safe collections for interested
> >>> clients in client update messages.  The fix for GEODE-7089 is to always
> >>> drain and remove the registration queue regardless of success or
> failure.
> >>> Together, these fixes prevent the failed registrations and memory leak.
> >>>
> >>> The SHAs for the fixes and tests in develop are:
> >>>
> >>> GEODE-7088
> >>> - 174af1d23fb7e09eb2bc2fa55479df854850fadb
> >>> - 5bb753a8f4ff2886acd8e62d6f51fea58e37881d
> >>>
> >>> GEODE-7089
> >>> - 5d0153ad4adb1612a1083673f98b1982819a6589
> >>>
> >>> This proposal is to cherry-pick these commits to 1.10.0 release branch.
> >>>
> >>> Thanks,
> >>> Ryan McMahon
> >>>
> >>
>
>

Re: [VOTE] Apache Geode 1.10.0.RC1

[Nabarun Nag]

Hello,

I was able to notice that after running the testSerializable JUnit test,
the generated actualSerializables.dat and the
sanctioned-geode-core-serializables.txt do not match. There are certain
classes mentioned in sanctioned-geode-core-serializables.txt that are not
present in actualSerializables.dat file

 - EvictionAttributes
 - ExpirationAttributes
 - MembershipAttributes
 - SubscriptionAttributes
 - EvictionAttributesImpl
 - PartitionAttributesImpl
 - CacheRealizaitonFunction


But removing them causes testSanctionedClassesExistAndDoDeserialize() test
to fail.

I am not sure if this is harmless or has some adverse consequences. I would
like to know why it's designed this way.

Regards
Nabarun Nag



On Wed, Sep 4, 2019 at 4:14 PM Dick Cavender  wrote:

> We manually signed the apache-geode-1.10.0-src.tgz dist and uploaded the
> asc file.
>
> Unclear on why this is no longer automatically generated as part of the
> build step as 1.9.1 it was generated correctly. We have worked around it in
> the prepare_rc.sh adding a check for it going forward and generating it if
> missing.
>
>
> On Wed, Sep 4, 2019 at 3:32 PM Dan Smith  wrote:
>
> > I don't see a .asc signature file for apache-geode-1.10.0-src.tgz. Did we
> > miss that signature file somehow?
> >
> > -Dan
> >
> > On Wed, Sep 4, 2019 at 9:33 AM Dick Cavender 
> wrote:
> >
> > > The apache-geode-native-1.10.0-src.tar.gz dist has been fixed in RC1
> and
> > > can be found at:
> > https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC1/
> > > Please continue to review RC1 as a viable 1.10 RC. The voting deadline
> > > remains 3PM PST Thursday Sept 5th.
> > >
> > > -Dick
> > >
> > >
> > > On Tue, Sep 3, 2019 at 3:09 PM Dan Smith  wrote:
> > >
> > > > Everything but the missing native source looks good. If we can fix
> > that,
> > > > I'll +1 this RC.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Sep 3, 2019 at 2:26 PM Dan Smith  wrote:
> > > >
> > > > > -1 It looks like this RC is also missing the native source, just
> like
> > > > > 1.9.1.RC3. The tar file is there, but it is empty.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Fri, Aug 30, 2019 at 2:06 PM Dick Cavender <
> dcaven...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > >> Hello Geode dev community,
> > > > >>
> > > > >> This is a release candidate for Apache Geode, version 1.10.0.RC1.
> > > > >> Thanks to all the community members for their contributions to
> this
> > > > >> release!
> > > > >>
> > > > >> Please do a review and give your feedback. The deadline is 3PM PST
> > > > >> Thursday
> > > > >> Sept 5th.
> > > > >> Release notes can be found at:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.10.0
> > > > >>
> > > > >> Please note that we are voting upon the source tags:
> rel/v1.10.0.RC1
> > > > >>
> > > > >> Apache Geode:
> > > > >> https://github.com/apache/geode/tree/rel/v1.10.0.RC1
> > > > >> Apache Geode examples:
> > > > >> https://github.com/apache/geode-examples/tree/rel/v1.10.0.RC1
> > > > >> Apache Geode native:
> > > > >> https://github.com/apache/geode-native/tree/rel/v1.10.0.RC1
> > > > >>
> > > > >> Source and binary files:
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC1/
> > > > >>
> > > > >> Maven staging repo:
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1058
> > > > >>
> > > > >> Geode's KEYS file containing PGP keys we use to sign the release:
> > > > >> https://github.com/apache/geode/blob/develop/KEYS
> > > > >>
> > > > >> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC1
> > > > >> -PgeodeRepositoryUrl=
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1058
> > > > >> build runAll
> > > > >>
> > > > >> Regards
> > > > >> Dick Cavender
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Apache Geode 1.10.0.RC1

[Nabarun Nag]

Hi Kirk,

The test does not fail.
When you run the test (testSerializable) it creates a list of serializable
classes and puts it in the actualSerializables.dat file and them compares
if all the classes listed are present in the
sanctioned-geode-core-serializables.txt.
If we did not change any serializabale classes then these two files
remain the same. However now in this release, there are classes in
sanctioned-geode-core-serializables.txt which are not present in
actualSerializables.dat.

I wanted to know why are those classes are not listed in
actualSerializables.dat
and if you remove them from sanctioned-geode-core-serializables.txt
testSerializables passes but testSanctionedClassesExistAndDoDeserialize
fails.

Regards
Naba


On Thu, Sep 5, 2019 at 3:21 PM Kirk Lund  wrote:

> Hi Naba,
>
> I failed to reproduce the problem you reported on Mac OS, and our pipeline
> didn't fail this test. What OS are you running integrationTest on? Here's
> the steps I followed:
>
> 1) checkout tag rel/v1.10.0.RC1
>
> $ git checkout tags/rel/v1.10.0.RC1
>
> 2) clean, then build with unit tests
>
> $ ./gradlew clean
> $ ./gradlew build
>
> 3) run AnalyzeSerializablesJUnitTest
>
> $ ./gradlew geode-core:integrationTest --tests
> AnalyzeSerializablesJUnitTest
>
> The test passes for me and there are no modified files in the repo after
> running the test. Did the test actually fail for you? If so, please share
> the call stack. If it is still failing for you I recommend getting a fresh
> clone of geode and then repeat the above steps.
>
> Thanks,
> Kirk
>
> On Thu, Sep 5, 2019 at 10:16 AM Nabarun Nag  wrote:
>
> > Hello,
> >
> > I was able to notice that after running the testSerializable JUnit test,
> > the generated actualSerializables.dat and the
> > sanctioned-geode-core-serializables.txt do not match. There are certain
> > classes mentioned in sanctioned-geode-core-serializables.txt that are not
> > present in actualSerializables.dat file
> >
> >  - EvictionAttributes
> >  - ExpirationAttributes
> >  - MembershipAttributes
> >  - SubscriptionAttributes
> >  - EvictionAttributesImpl
> >  - PartitionAttributesImpl
> >  - CacheRealizaitonFunction
> >
> >
> > But removing them causes testSanctionedClassesExistAndDoDeserialize()
> test
> > to fail.
> >
> > I am not sure if this is harmless or has some adverse consequences. I
> would
> > like to know why it's designed this way.
> >
> > Regards
> > Nabarun Nag
> >
> >
> >
> > On Wed, Sep 4, 2019 at 4:14 PM Dick Cavender 
> wrote:
> >
> > > We manually signed the apache-geode-1.10.0-src.tgz dist and uploaded
> the
> > > asc file.
> > >
> > > Unclear on why this is no longer automatically generated as part of the
> > > build step as 1.9.1 it was generated correctly. We have worked around
> it
> > in
> > > the prepare_rc.sh adding a check for it going forward and generating it
> > if
> > > missing.
> > >
> > >
> > > On Wed, Sep 4, 2019 at 3:32 PM Dan Smith  wrote:
> > >
> > > > I don't see a .asc signature file for apache-geode-1.10.0-src.tgz.
> Did
> > we
> > > > miss that signature file somehow?
> > > >
> > > > -Dan
> > > >
> > > > On Wed, Sep 4, 2019 at 9:33 AM Dick Cavender 
> > > wrote:
> > > >
> > > > > The apache-geode-native-1.10.0-src.tar.gz dist has been fixed in
> RC1
> > > and
> > > > > can be found at:
> > > > https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC1/
> > > > > Please continue to review RC1 as a viable 1.10 RC. The voting
> > deadline
> > > > > remains 3PM PST Thursday Sept 5th.
> > > > >
> > > > > -Dick
> > > > >
> > > > >
> > > > > On Tue, Sep 3, 2019 at 3:09 PM Dan Smith 
> wrote:
> > > > >
> > > > > > Everything but the missing native source looks good. If we can
> fix
> > > > that,
> > > > > > I'll +1 this RC.
> > > > > >
> > > > > > -Dan
> > > > > >
> > > > > > On Tue, Sep 3, 2019 at 2:26 PM Dan Smith 
> > wrote:
> > > > > >
> > > > > > > -1 It looks like this RC is also missing the native source,
> just
> > > like
> > > > > > > 1.9.1.RC3. The tar file is there, but it is empty.
> > > > > > >
> > > > > > > -Dan
&

Re: [VOTE] Apache Geode 1.10.0.RC1

[Nabarun Nag]

Thank you Dan for the explanation.

Regards
Naba


On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:

> Hi Naba,
>
> This sanctioned-serializable stuff is not an issue.
>
> When you removed those files from sanctioned-geode-core-serializables, they
> get rejected by the serialization filter. Look at the error message you see
> when you remove them - it is failing to serialize a class that has a
> *nested* EvictionAttributes.
>
> Those classes need to be in the sanctioned file, if they are embedded in
> another serialized object. They are probably not showing up in the
> actualSerializables file because they are DataSerializable.
>
> -Dan
>
> On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
>
> > Ah, ok. I think I see what you're asking about. I don't have an answer,
> but
> > someone else such as Bruce could explain it.
> >
> > /Users/klund/dev/geode3 [610]$ diff
> >
> >
> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
> > geode-core/build/integrationTest/actualSerializables.dat
> > 69d68
> > < org/apache/geode/cache/EvictionAttributes,false
> > 71d69
> > < org/apache/geode/cache/ExpirationAttributes,false
> > 79d76
> > < org/apache/geode/cache/MembershipAttributes,false
> > 99d95
> > < org/apache/geode/cache/SubscriptionAttributes,false
> > 262d257
> > < org/apache/geode/internal/cache/EvictionAttributesImpl,false
> > 276d270
> > < org/apache/geode/internal/cache/PartitionAttributesImpl,false
> > 517d510
> > <
> >
> >
> org/apache/geode/management/internal/cli/functions/CacheRealizationFunction,false
> >
> > On Thu, Sep 5, 2019 at 3:44 PM Nabarun Nag  wrote:
> >
> > > Hi Kirk,
> > >
> > > The test does not fail.
> > > When you run the test (testSerializable) it creates a list of
> > serializable
> > > classes and puts it in the actualSerializables.dat file and them
> compares
> > > if all the classes listed are present in the
> > > sanctioned-geode-core-serializables.txt.
> > > If we did not change any serializabale classes then these two files
> > > remain the same. However now in this release, there are classes in
> > > sanctioned-geode-core-serializables.txt which are not present in
> > > actualSerializables.dat.
> > >
> > > I wanted to know why are those classes are not listed in
> > > actualSerializables.dat
> > > and if you remove them from sanctioned-geode-core-serializables.txt
> > > testSerializables passes but testSanctionedClassesExistAndDoDeserialize
> > > fails.
> > >
> > > Regards
> > > Naba
> > >
> > >
> > > On Thu, Sep 5, 2019 at 3:21 PM Kirk Lund  wrote:
> > >
> > > > Hi Naba,
> > > >
> > > > I failed to reproduce the problem you reported on Mac OS, and our
> > > pipeline
> > > > didn't fail this test. What OS are you running integrationTest on?
> > Here's
> > > > the steps I followed:
> > > >
> > > > 1) checkout tag rel/v1.10.0.RC1
> > > >
> > > > $ git checkout tags/rel/v1.10.0.RC1
> > > >
> > > > 2) clean, then build with unit tests
> > > >
> > > > $ ./gradlew clean
> > > > $ ./gradlew build
> > > >
> > > > 3) run AnalyzeSerializablesJUnitTest
> > > >
> > > > $ ./gradlew geode-core:integrationTest --tests
> > > > AnalyzeSerializablesJUnitTest
> > > >
> > > > The test passes for me and there are no modified files in the repo
> > after
> > > > running the test. Did the test actually fail for you? If so, please
> > share
> > > > the call stack. If it is still failing for you I recommend getting a
> > > fresh
> > > > clone of geode and then repeat the above steps.
> > > >
> > > > Thanks,
> > > > Kirk
> > > >
> > > > On Thu, Sep 5, 2019 at 10:16 AM Nabarun Nag  wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I was able to notice that after running the testSerializable JUnit
> > > test,
> > > > > the generated actualSerializables.dat and the
> > > > > sanctioned-geode-core-serializables.txt do not match. There are
> > certain
> > > > > classes mentioned in sanctioned-geode-core-serializables.txt that
> are
> > > not
> > > > > present in actualSeria

Re: [VOTE] Apache Geode 1.9.1.RC3

[Nabarun Nag]

Can anyone confirm that the native client test failure happening in 1.10 RC
does not occur in this candidate.
I can test it if someone can point me to the instructions to do that.


Regards
Naba


On Fri, Sep 6, 2019 at 8:38 AM Robert Houghton  wrote:

> +1 given the pre-existence of threw class path bug, and it's fix in 1.10
>
> On Wed, Sep 4, 2019, 11:26 Jens Deppe  wrote:
>
> > No, It's fixed in 1.10.x.
> >
> > On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
> > wrote:
> >
> > > Hi Jens,
> > >
> > > Does this issue appear in 1.10.0.RC1?
> > >
> > > On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
> > >
> > > > TL;DR: +0
> > > >
> > > > When using gfsh over http, the following exception occurs:
> > > >
> > > > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> > > >
> > > >
> > >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > <
> > >
> >
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > >
> > > >
> > > > Exception in thread "main" java.lang.NoClassDefFoundError:
> > > > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > > > at
> > > >
> > org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > > > Caused by: java.lang.ClassNotFoundException:
> > > > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > > > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > > ... 19 more
> > > >
> > > > The problem is that the geode-web.jar is not included in
> > > > gfsh-dependencies.jar as part of the build.
> > > >
> > > > Since this issue appears to also exist on 1.9.0 I'm going to +0
> > (instead
> > > of
> > > > -1). Others may feel differently. A workaround exists simply by
> adding
> > > the
> > > > missing jar when running gfsh.
> > > >
> > > > --Jens
> > > >
> > > > On Tue, Sep 3, 2019 at 10:45 AM John Blum  wrote:
> > > >
> > > > > 1 more thing...
> > > > >
> > > > > I would additionally advise rewording the sentence...
> > > > >
> > > > > *> Please add log4j-core to the classpath.*
> > > > >
> > > > > To read...
> > > > >
> > > > > "*Please consider adding log4j-core, or another Logging provider
> > (e.g.
> > > > > Logback), to your classpath.  Apache Geode works best with Log4j.*"
> > > > >
> > > > > Food for thought.
> > > > >
> > > > > -John
> > > > >
> > > > >
> > > > > On Tue, Sep 3, 2019 at 10:40 AM John Blum 
> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Ran SDG build against Apache G

Re: [VOTE] Apache Geode 1.10.0.RC1

[Nabarun Nag]

adle scripts that use the
> git plugin aren’t catch that exception like they used to do (works on
> 1.9.1).
> >
> > Since the source archive is the official release and I can’t build it,
> I”m voting -1.  I would change my vote if we can fix this.
> >
> > Anthony
> >
> >
> >> On Sep 6, 2019, at 8:19 AM, Anthony Baker  wrote:
> >>
> >> I think we should extend the vote in order to understand this issue
> better.
> >>
> >> Anthony
> >>
> >>
> >>> On Sep 6, 2019, at 12:41 AM, Ivan Godwin  wrote:
> >>>
> >>> Hello,
> >>>
> >>> I don't know that this will be cause to hold anything up, but
> geode-native
> >>> has two integration tests failing when trying to perform
> Region::remove().
> >>> This is the case for all platforms supported by native client. The two
> >>> tests are testThinClientCallbackArg and
> >>> testThinClientListenerCallbackArgTest.
> >>>
> >>> Here's the stacktrace, and I will continue investigating in the
> morning.
> >>>
> >>> Region::remove: An exception (java.lang.ClassCastException:
> >>> java.lang.Byte cannot be cast to org.apache.geode.cache.Operation
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.getOperation(BaseCommand.java:1466)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> >>>
> >>> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> >>>
> >>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> >>>
> >>> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:666)
> >>>
> >>> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> >>>
> >>> at java.lang.Thread.run(Thread.java:748)
> >>>
> >>> ) happened at remote server.
> >>>
> >>>
> >>> On Thu, Sep 5, 2019 at 9:00 PM Nabarun Nag  wrote:
> >>>
> >>>> Thank you Dan for the explanation.
> >>>>
> >>>> Regards
> >>>> Naba
> >>>>
> >>>>
> >>>> On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:
> >>>>
> >>>>> Hi Naba,
> >>>>>
> >>>>> This sanctioned-serializable stuff is not an issue.
> >>>>>
> >>>>> When you removed those files from
> sanctioned-geode-core-serializables,
> >>>> they
> >>>>> get rejected by the serialization filter. Look at the error message
> you
> >>>> see
> >>>>> when you remove them - it is failing to serialize a class that has a
> >>>>> *nested* EvictionAttributes.
> >>>>>
> >>>>> Those classes need to be in the sanctioned file, if they are
> embedded in
> >>>>> another serialized object. They are probably not showing up in the
> >>>>> actualSerializables file because they are DataSerializable.
> >>>>>
> >>>>> -Dan
> >>>>>
> >>>>> On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
> >>>>>
> >>>>>> Ah, ok. I think I see what you're asking about. I don't have an
> answer,
> >>>>> but
> >>>>>> someone else such as Bruce could explain it.
> >>>>>>
> >>>>>> /Users/klund/dev/geode3 [610]$ diff
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
> >>>>

[VOTE] Adding new AEQ feature to release/1.10.0

[Nabarun Nag]

Hi Geode Community ,

[GEODE-7121]

I would like to include the new feature of creating AEQs with a paused
event processor to the release 1.10 branch. This also includes the feature
to resume the AEQ at a later point in time.
This feature includes addition of new/modified APIs and gfsh commands.

[All details about this feature has been discussed in a previous discuss
thread]

These are the commits that needs to be in release 1.10.0 branch.
f6e11084daa30791f7bbf9a8187f6d1bc9c4b91a
615d3399d24810126a6d57b5163f7afcd06366f7
1440a95e266e671679a623f93865c5e7e683244f
42e07dc9054794657acb40c292f3af74b79a1ea6
e1f200e2f9e77e986d250fde3848dc004b26a7c2
5f70160fba08a06c7e1fc48c7099e63dd1a0502b
0645446ec626bc351a2c881e4df6a4ae2e75fbfc
575c6bac115112df1e84455b052566c75764b0be
3d9627ff16443f4aa513a67bcc284e68953aff8a
ea22e72916f8e34455800d347690e483727f9bf5
8d26d595f5fb94ff703116eb91bb747e9ba7f536

Will create a PR ASAP.

Regards
Nabarun Nag

Re: [VOTE] Adding new AEQ feature to release/1.10.0

[Nabarun Nag]

No not yet. The documentation tickets got resolved Friday afternoon and
hence the PR will be created today.

Regards
Naba


On Mon, Sep 16, 2019 at 8:52 AM Dick Cavender  wrote:

> Naba-
>
> Do you have this PR ready to merge to release/1.10.0 since we seem to have
> the votes for this to happen?
>
>
>
> On Mon, Sep 16, 2019 at 7:08 AM Jens Deppe  wrote:
>
> > +1
> >
> > On Mon, Sep 16, 2019 at 3:08 AM Juan José Ramos 
> wrote:
> >
> > > +1
> > >
> > > On Fri, Sep 13, 2019 at 11:59 PM Ryan McMahon 
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Sep 13, 2019 at 3:58 PM Donal Evans 
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Fri, Sep 13, 2019 at 3:37 PM Benjamin Ross 
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Fri, Sep 13, 2019 at 3:25 PM Anilkumar Gingade <
> > > aging...@pivotal.io
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1. This is needed for spring data-geode; whose upcoming
> release
> > is
> > > > > based
> > > > > > > on older geode version.
> > > > > > >
> > > > > > > -Anil.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 13, 2019 at 3:23 PM Nabarun Nag 
> > > wrote:
> > > > > > >
> > > > > > > > Hi Geode Community ,
> > > > > > > >
> > > > > > > > [GEODE-7121]
> > > > > > > >
> > > > > > > > I would like to include the new feature of creating AEQs
> with a
> > > > > paused
> > > > > > > > event processor to the release 1.10 branch. This also
> includes
> > > the
> > > > > > > feature
> > > > > > > > to resume the AEQ at a later point in time.
> > > > > > > > This feature includes addition of new/modified APIs and gfsh
> > > > > commands.
> > > > > > > >
> > > > > > > > [All details about this feature has been discussed in a
> > previous
> > > > > > discuss
> > > > > > > > thread]
> > > > > > > >
> > > > > > > > These are the commits that needs to be in release 1.10.0
> > branch.
> > > > > > > > f6e11084daa30791f7bbf9a8187f6d1bc9c4b91a
> > > > > > > > 615d3399d24810126a6d57b5163f7afcd06366f7
> > > > > > > > 1440a95e266e671679a623f93865c5e7e683244f
> > > > > > > > 42e07dc9054794657acb40c292f3af74b79a1ea6
> > > > > > > > e1f200e2f9e77e986d250fde3848dc004b26a7c2
> > > > > > > > 5f70160fba08a06c7e1fc48c7099e63dd1a0502b
> > > > > > > > 0645446ec626bc351a2c881e4df6a4ae2e75fbfc
> > > > > > > > 575c6bac115112df1e84455b052566c75764b0be
> > > > > > > > 3d9627ff16443f4aa513a67bcc284e68953aff8a
> > > > > > > > ea22e72916f8e34455800d347690e483727f9bf5
> > > > > > > > 8d26d595f5fb94ff703116eb91bb747e9ba7f536
> > > > > > > >
> > > > > > > > Will create a PR ASAP.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Nabarun Nag
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Juan José Ramos Cassella
> > > Senior Software Engineer
> > > Email: jra...@pivotal.io
> > >
> >
>

Re: [VOTE] Adding a lucene specific fix to release/1.10.0

[Nabarun Nag]

+1

On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou  wrote:

> I want to merge GEODE-7208, which is lucene specific fix
>
> The fix will enable indexing on inherited attributes in user object.
>
> revision 4ec87419d456748a7d853e979c90ad4e301b2405
>
> Regards
> Gester
>

Re: [DISCUSS] - Cutting of release 1.9.2

[Nabarun Nag]

Just out of curiosity, do we have preliminary tests done to ensure that all
the tasks under GEODE-7121 are enough to implement the solution by Spring
Data Gemfire to solve the deadlock issue?

+1 to include the fix.

On Fri, Sep 20, 2019 at 1:13 PM John Blum  wrote:

> +1 for releasing Apache Geode 1.9.2 and including the fix for GEDOE-7121.
>
> On Fri, Sep 20, 2019 at 1:11 PM Kirk Lund  wrote:
>
> > +1 for creating 1.9.x with the fix for GEODE-7121
> >
> >
> > On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:
> >
> > > Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which
> is
> > > tentatively scheduled for Monday, Sept. 30th.
> > >
> > > On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
> > >
> > > > Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG
> > > 2.2.0?
> > > >
> > > > On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer 
> wrote:
> > > >
> > > > > Hi there Geode Dev's,
> > > > >
> > > > > I would like to propose a release for Geode 1.9.x that includes
> > > > > https://issues.apache.org/jira/browse/GEODE-7121.
> > > > >
> > > > > This is an issue that is current in the 1.9.x branch, which is used
> > by
> > > > > Spring Data Geode 2.1.10 <
> > https://spring.io/projects/spring-data-geode
> > > >.
> > > > >
> > > > > This issue can cause an application using Spring Data Geode to
> > > bootstrap
> > > > > GEODE to deadlock upon start up.
> > > > >
> > > > > This is critical system's issue and given that Spring Data Geode
> > cannot
> > > > > change its underlying dependency to 1.10+, would require this fix
> to
> > be
> > > > > back-ported to the 1.9 branch.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
>
>
> --
> -John
> john.blum10101 (skype)
>

[DISCUSS] Blocking merge button in PR

[Nabarun Nag]

Hi devs,

A few months ago a proposal was brought up regarding blocking the merge
button on the github PR page in case of failing tests in the precheck.

What is the sentiment regarding this now? Do we feel that it should be
implemented?

Or at least take the minimal step of not allowing merge till all tests are
done?


Regards
Nabarun Nag

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

@Bruce Schuchardt 
I completely agree with that assessment that not all flaky tests are
related to the test but may involve issues with the product itself.

@Ernie
As you can see with the example that you provided, even when committers are
expected to do their due diligence they sometimes end up doing something
that needs to be reverted.

It's ok to have some safeguards. I plan to look at them like seatbelts in a
car, even when we are diligent, unexpected things happen.

My intention with this email was *never* to blame others / point out PRs
that broke the build, etc.
I want guard rails that will help even me from making mistakes.

I understand that the consensus is that distributed/integration/upgrade
tests at the moment are flaky, hence blocking the merge button because of
them will not be an efficient call.

*NEW PROPOSAL*: baby steps.
*Github's Branch Protection Rule *has the following rule settings that I
propose to activate:
- Require pull request reviews before merging
- Require status checks to pass before merging
 [Only for
- concourse-ci/Build
   - concourse-ci/UnitTestOpenJDK11
   - concourse-ci/UnitTestOpenJDK8
   - concourse-ci/StressNewTestOpenJDK11]

*Advantages:*
- Prevent us from accidentally merging PRs without reviews, ensure that we
follow *the Apache way* of involving the community in what code is going
into the repo.
- Our build is not flaky, hence it helps us in avoiding merging code which
will break the build
- Avoid mistakenly merging spotless errors
- Unit tests are not flaky hence they can be included
- Any new tests that are being added can't be merged if they fail the
stress test.


 Apache values people over process, I highly appreciate that sentiment but
they never said not to take help from tools to save time and avoid mistakes.

If we search for this feature in INFRA tickets, a lot of Apache projects
have enabled this feature for their repositories.

Regards
Naba



On Fri, Oct 18, 2019 at 1:39 PM Bruce Schuchardt 
wrote:

> Given the current state of affairs I don't think we should disable the
> merge button.
>
> Ultimately it would be nice if we fixed all of the flaky tests.
> Personally I don't think all of the tests that we think are "flaky" are
> test problems.  In the last few months I've fixed product problems that
> were hit by supposedly "flaky" tests.  Those tests were just unable to
> reproduce the product problem 100% of the time.  A flickering test
> doesn't always mean it's a problem with the test.
>
> On 10/18/19 12:46 PM, Ernest Burghardt wrote:
> > I had one recently that was Approved and I merged pre-maturely and had to
> > be reverted: d63638e4654bc6c71a232838b745dec6ef476ec9
> >
> > Subsequently I have run into some test flakiness, but if a PR submitter
> has
> > a pre-checkin failure it could be tricky to tell that its a Flaky
> > situation... In my last go at a Flaky failure in pre-checkin, I was able
> to
> > search the Geode Jira and found the failure was a known flaky like this
> one
> > <https://issues.apache.org/jira/browse/GEODE-6324>
> >
> > I'd prefer to trust our committers to perform their due diligence and
> make
> > good choices.
> >
> > EB
> >
> > On Fri, Oct 18, 2019 at 12:18 PM Owen Nichols 
> wrote:
> >
> >> Do you have a recent example of a PR that was merged despite failed PR
> >> checks, which then broke the build?
> >>
> >> At last discussion, one concern raised was providing a way that anyone
> in
> >> the community could re-trigger a failed PR check if it hit an unrelated
> >> flaky failure.
> >>
> >> Let’s be sure we've identified the problem before assuming the solution.
> >> Apache values people over process.
> >>
> >>> On Oct 18, 2019, at 11:48 AM, Nabarun Nag  wrote:
> >>>
> >>> Hi devs,
> >>>
> >>> A few months ago a proposal was brought up regarding blocking the merge
> >>> button on the github PR page in case of failing tests in the precheck.
> >>>
> >>> What is the sentiment regarding this now? Do we feel that it should be
> >>> implemented?
> >>>
> >>> Or at least take the minimal step of not allowing merge till all tests
> >> are
> >>> done?
> >>>
> >>>
> >>> Regards
> >>> Nabarun Nag
> >>
>

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

No one felt one review was too much. At least one is bare minimum.

Regards
Naba


On Sat, Oct 19, 2019 at 11:33 AM Owen Nichols  wrote:

> +1 for starting with only Build, Unit, and Stress tests.
>
> When you say you propose to "require pull request reviews" before merging,
> what number of reviews are you proposing?  When we discussed this before <
> https://lists.apache.org/thread.html/3e9a78a474b15d900244a86ed80358e59f4836a36e7368ae15eeeb17@%3Cdev.geode.apache.org%3E>
> nearly everyone felt that “3” was way too high but also some people even
> thought “1” was too high.  The consensus then was to leave it up to the PR
> author how many reviews, if any, they needed to feel comfortable.
>
> It looks like any committer can bypass there GitHub safeguards if they
> wish just by committing directly to develop, so I guess that this proposal
> remains compatible with “people over process”.
>
> -Owen
>
> > On Oct 18, 2019, at 4:11 PM, Alexander Murmann 
> wrote:
> >
> > +1 for the 👶 steps proposal
> >
> > On Fri, Oct 18, 2019 at 3:30 PM Donal Evans  wrote:
> >
> >> Big +1 from me on the revised proposal. It seems like there'd rarely be
> >> a case where something needs to be merged so fast that we can't even
> wait
> >> for the build and unit tests to pass, and preventing the addition of
> flaky
> >> tests by running the StressNewTest might help address the apparent
> trend
> >> of increase in flakiness thats been talked about.
> >>
> >> On Fri, Oct 18, 2019 at 3:15 PM Nabarun Nag  wrote:
> >>
> >>> @Bruce Schuchardt 
> >>> I completely agree with that assessment that not all flaky tests are
> >>> related to the test but may involve issues with the product itself.
> >>>
> >>> @Ernie
> >>> As you can see with the example that you provided, even when committers
> >> are
> >>> expected to do their due diligence they sometimes end up doing
> something
> >>> that needs to be reverted.
> >>>
> >>> It's ok to have some safeguards. I plan to look at them like seatbelts
> >> in a
> >>> car, even when we are diligent, unexpected things happen.
> >>>
> >>> My intention with this email was *never* to blame others / point out
> PRs
> >>> that broke the build, etc.
> >>> I want guard rails that will help even me from making mistakes.
> >>>
> >>> I understand that the consensus is that distributed/integration/upgrade
> >>> tests at the moment are flaky, hence blocking the merge button because
> of
> >>> them will not be an efficient call.
> >>>
> >>> *NEW PROPOSAL*: baby steps.
> >>> *Github's Branch Protection Rule *has the following rule settings that
> I
> >>> propose to activate:
> >>> - Require pull request reviews before merging
> >>> - Require status checks to pass before merging
> >>> [Only for
> >>>- concourse-ci/Build
> >>>   - concourse-ci/UnitTestOpenJDK11
> >>>   - concourse-ci/UnitTestOpenJDK8
> >>>   - concourse-ci/StressNewTestOpenJDK11]
> >>>
> >>> *Advantages:*
> >>> - Prevent us from accidentally merging PRs without reviews, ensure that
> >> we
> >>> follow *the Apache way* of involving the community in what code is
> going
> >>> into the repo.
> >>> - Our build is not flaky, hence it helps us in avoiding merging code
> >> which
> >>> will break the build
> >>> - Avoid mistakenly merging spotless errors
> >>> - Unit tests are not flaky hence they can be included
> >>> - Any new tests that are being added can't be merged if they fail the
> >>> stress test.
> >>>
> >>>
> >>> Apache values people over process, I highly appreciate that sentiment
> >> but
> >>> they never said not to take help from tools to save time and avoid
> >>> mistakes.
> >>>
> >>> If we search for this feature in INFRA tickets, a lot of Apache
> projects
> >>> have enabled this feature for their repositories.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>>
> >>> On Fri, Oct 18, 2019 at 1:39 PM Bruce Schuchardt <
> bschucha...@pivotal.io
> >>>
> >>> wrote:
> >>>
> >>>> Given the current state of affai

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

@Karen

Thank you so much for the feedback. I understand that committers must trust
each other and I agree entirely with that. This proposal is just preventing
us from making mistakes. Its just guard rails. As you can see in the email
chain that this mistake was made multiple times and this has let to a lot
of engineers give up their time and detecting and fixing this issue. We
still trust our committers, we are just enabling some features to avoid
time being wasted on avoidable mistakes and use that time in
improving Geode. I hope I can persuade you to change your opinion.

@Owen
Thank you for accepting the baby step proposal. Yes, let's see in some time
if this is successful. We can always undo this if needed.

@Rest
- Blaming people etc. will be very detrimental to the community, I do not
propose that.
- This proposal was not just my idea but from feedback from lot of
developers who contribute to Geode on a frequent basis.
- It is very* unfair *to the engineers to go and investigate and find out
what caused the failure and then send emails etc, their time can be used in
doing something more valuable.
- This is not something new, we have had this issue for over 3 years now,
and maintaining this as the status quo is not healthy. Let us try this
solution, the committers, and developers who contribute on a regular basis
will immediately see if it works or does not work and can revert it if this
does not.
- There is a problem and this is an attempt at the solution. If it does not
work, we can revert it. For the sake of all the developers who are in pain
and helping them spend the time on more productive tasks, let us just give
this proposal a chance. If there are any issues we can revert it.


*Reiterating the proposal:*
Github branch protection rule for :
- at least one review
- Passing build, unit and stress test.


In our opinion, no committer would want to check-in code with failing any
of the above.

Regards
Nabarun

On Mon, Oct 21, 2019 at 10:28 AM Alexander Murmann 
wrote:

> Udo, I think you are making a great point! I am fully bought into trusting
> our committers to know how many reviews are needed for their PRs. We should
> be able to have the same trust into knowing when it's OK to merge. If a
> committer wants to they can after all, always merge and push without a PR.
> That's because we trust them.
>
> If we are seeing that our committers merge without sufficient review (via
> human or automated means), is this an education problem we can solve?
>
> On Mon, Oct 21, 2019 at 10:18 AM Udo Kohlmeyer  wrote:
>
> > I must agree with @Karen here..
> >
> > All committers are trusted to do the right thing. One of those things is
> > to commit (or not commit) PR's.
> >
> > Now we are discussing disabling the button when tests are failing. Why
> > stop there? Why not, that the submitter of the said commit does not get
> > to merge their own PR?
> >
> > Now, that of course is taking it to the extreme, that we don't want (at
> > least I don't want to be THAT over prescriptive).. So why do we want to
> > now limit when I can merge? It remains the committers responsibility to
> > merge commits into the project, that are of the expected quality. IF it
> > so happens that one, by accident, has merged a PR before it was green,
> > revert it. All committers have the power to do so.
> >
> > So from my perspective, a -1 on disabling the Merge button, just because
> > someone was not careful in merging and without following our protocol of
> > waiting for an "All green".
> >
> > --Udo
> >
> > On 10/21/19 10:11 AM, Ernest Burghardt wrote:
> > > +1 to enacting this immediately... just this weekend a PR was merged
> with
> > > failures on all of the following:
> > > * concourse-ci/DistributedTestOpenJDK11 * Concourse CI build failure
> > > * concourse-ci/UnitTestOpenJDK11 * Concourse CI build failure
> > > * concourse-ci/UnitTestOpenJDK8 * Concourse CI build failure
> > > * concourse-ci/UpgradeTestOpenJDK11 * Concourse CI build failure
> > >
> > >
> > > Thanks,
> > > EB
> > >
> > > On Mon, Oct 21, 2019 at 10:01 AM Karen Miller 
> > wrote:
> > >
> > >> I have (more than once) committed docs changes for typo fixes without
> > >> review.  I generally label the commits
> > >> with a bold "Commit then Review" message.  But, I am bringing this up
> > as I
> > >> have purposely not followed what
> > >> looks to be a positively-received proposed policy, since I have not
> > gotten
> > >> reviews. If all feel that we need a
> > >> rule for everyone to follow (instead of a guideline that PRs shall
> have
> > at
> > >> least 1 review), I will follow the rule,
> > >> but I'm a -0 on the process. I get it, and I understand its purpose
> and
> > >> intent, but I personally prefer to trust that each
> > >> comitter takes personal responsibility for the code they commit WRT
> > waiting
> > >> for tests and/or obtaining reviews.
> > >> Karen
> > >>
> > >>
> > >> On Mon, Oct 21, 2019 at 6:24 AM Joris Melchior 
> > >> wrote:
> > >>
> > >

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

Thank you all for all the valuable feedback. Robert was kind enough to
check the technical feasibility of the integration of Github Branch
Protection Rules and its compatibility with our concourse CI checks and we
are satisfied with the settings provided and the initial tests that Robert
did with a demo geode branch. Please find attached the screenshot of the
settings that will be sent to INFRA for enabling it on the Apache Geode
repository.

Regards
Nabarun

On Mon, Oct 21, 2019 at 12:21 PM Aaron Lindsey  wrote:

> +1
>
> - Aaron
>
>
> On Mon, Oct 21, 2019 at 11:53 AM Udo Kohlmeyer  wrote:
>
> > BIG +1 (Yes, I'm changing my -1)
> >
> > @Naba, thank you for the offline chat. It seems that the proposal of
> > Github enforcing our good practices is a great option.
> >
> > 2 merged PR's without a full green pipeline, since 18 Oct 2019, shocking
> > and disgusting!!
> >
> > I would just like to reiterate to ALL committers, you have a
> > responsibility towards the project to commit/merge only the best code
> > possible. If things break, fix them. Don't merge and hope that it goes
> > away and someone else fixes it.
> >
> > I really don't want to support a mechanism where the project has become
> > so prescriptive and restrictive, all because we have a few committers
> > who will not follow the established and agreed processes. BUT, once
> > again, the masses are impacted due to a few.
> >
> > Thank you Naba for following this through.
> >
> > --Udo
> >
> > On 10/21/19 11:05 AM, Nabarun Nag wrote:
> > > @Karen
> > >
> > > Thank you so much for the feedback. I understand that committers must
> > trust
> > > each other and I agree entirely with that. This proposal is just
> > preventing
> > > us from making mistakes. Its just guard rails. As you can see in the
> > email
> > > chain that this mistake was made multiple times and this has let to a
> lot
> > > of engineers give up their time and detecting and fixing this issue. We
> > > still trust our committers, we are just enabling some features to avoid
> > > time being wasted on avoidable mistakes and use that time in
> > > improving Geode. I hope I can persuade you to change your opinion.
> > >
> > > @Owen
> > > Thank you for accepting the baby step proposal. Yes, let's see in some
> > time
> > > if this is successful. We can always undo this if needed.
> > >
> > > @Rest
> > > - Blaming people etc. will be very detrimental to the community, I do
> not
> > > propose that.
> > > - This proposal was not just my idea but from feedback from lot of
> > > developers who contribute to Geode on a frequent basis.
> > > - It is very* unfair *to the engineers to go and investigate and find
> out
> > > what caused the failure and then send emails etc, their time can be
> used
> > in
> > > doing something more valuable.
> > > - This is not something new, we have had this issue for over 3 years
> now,
> > > and maintaining this as the status quo is not healthy. Let us try this
> > > solution, the committers, and developers who contribute on a regular
> > basis
> > > will immediately see if it works or does not work and can revert it if
> > this
> > > does not.
> > > - There is a problem and this is an attempt at the solution. If it does
> > not
> > > work, we can revert it. For the sake of all the developers who are in
> > pain
> > > and helping them spend the time on more productive tasks, let us just
> > give
> > > this proposal a chance. If there are any issues we can revert it.
> > >
> > >
> > > *Reiterating the proposal:*
> > > Github branch protection rule for :
> > > - at least one review
> > > - Passing build, unit and stress test.
> > >
> > >
> > > In our opinion, no committer would want to check-in code with failing
> any
> > > of the above.
> > >
> > > Regards
> > > Nabarun
> > >
> > > On Mon, Oct 21, 2019 at 10:28 AM Alexander Murmann <
> amurm...@apache.org>
> > > wrote:
> > >
> > >> Udo, I think you are making a great point! I am fully bought into
> > trusting
> > >> our committers to know how many reviews are needed for their PRs. We
> > should
> > >> be able to have the same trust into knowing when it's OK to merge. If
> a
> > >> committer wants to they can after all, always merge and push wi

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

Darrel,

In my opinion, Stress new tests is one of the important test suites that
needs to be activated. This is only test suite that can prevent the influx
of flaky tests. We have seen a heavy rise in the number of tickets being
created recently.

Old tests can be avoided from running in the suite for the PR by keeping it
unchanged. A separate new ticket can be created with a refactoring task and
that PR should handle the flaky ness of the test along with the refactoring.

Regards
Naba





On Tue, Oct 22, 2019 at 8:34 AM Darrel Schneider 
wrote:

> I would advise against including "StressNewTestOpenJDK11".
> I have had trouble with this one when doing something as simple as a method
> rename.
> Because that method was called from an old test, StressNewTest ran that old
> test many times. Not all of our current tests can handle being rerun many
> times. If all you are trying to do in a pull request is something simple
> you should not be required to rework a test to survive StressNewTest.
> If StressNewTest was changed to only run brand new test files then I would
> be okay with it gating a PR merge.
>
> On Mon, Oct 21, 2019 at 4:41 PM Bruce Schuchardt 
> wrote:
>
> > I'd still like to see the PR rerun tool or an equivalent available to
> > everyone.  Sure you can push an empty commit but that reruns everything,
> > but the PR tool lets you rerun only the checks that failed.
> >
> > On 10/21/19 3:04 PM, Ernest Burghardt wrote:
> > > +1
> > > @Naba thanks for seeing this through!
> > >
> > > On Mon, Oct 21, 2019 at 1:51 PM Nabarun Nag  wrote:
> > >
> > >> Thank you all for all the valuable feedback. Robert was kind enough to
> > >> check the technical feasibility of the integration of Github Branch
> > >> Protection Rules and its compatibility with our concourse CI checks
> and
> > we
> > >> are satisfied with the settings provided and the initial tests that
> > Robert
> > >> did with a demo geode branch. Please find attached the screenshot of
> the
> > >> settings that will be sent to INFRA for enabling it on the Apache
> Geode
> > >> repository.
> > >>
> > >> Regards
> > >> Nabarun
> > >>
> > >> On Mon, Oct 21, 2019 at 12:21 PM Aaron Lindsey 
> > >> wrote:
> > >>
> > >>> +1
> > >>>
> > >>> - Aaron
> > >>>
> > >>>
> > >>> On Mon, Oct 21, 2019 at 11:53 AM Udo Kohlmeyer 
> wrote:
> > >>>
> > >>>> BIG +1 (Yes, I'm changing my -1)
> > >>>>
> > >>>> @Naba, thank you for the offline chat. It seems that the proposal of
> > >>>> Github enforcing our good practices is a great option.
> > >>>>
> > >>>> 2 merged PR's without a full green pipeline, since 18 Oct 2019,
> > shocking
> > >>>> and disgusting!!
> > >>>>
> > >>>> I would just like to reiterate to ALL committers, you have a
> > >>>> responsibility towards the project to commit/merge only the best
> code
> > >>>> possible. If things break, fix them. Don't merge and hope that it
> goes
> > >>>> away and someone else fixes it.
> > >>>>
> > >>>> I really don't want to support a mechanism where the project has
> > become
> > >>>> so prescriptive and restrictive, all because we have a few
> committers
> > >>>> who will not follow the established and agreed processes. BUT, once
> > >>>> again, the masses are impacted due to a few.
> > >>>>
> > >>>> Thank you Naba for following this through.
> > >>>>
> > >>>> --Udo
> > >>>>
> > >>>> On 10/21/19 11:05 AM, Nabarun Nag wrote:
> > >>>>> @Karen
> > >>>>>
> > >>>>> Thank you so much for the feedback. I understand that committers
> must
> > >>>> trust
> > >>>>> each other and I agree entirely with that. This proposal is just
> > >>>> preventing
> > >>>>> us from making mistakes. Its just guard rails. As you can see in
> the
> > >>>> email
> > >>>>> chain that this mistake was made multiple times and this has let
> to a
> > >>> lot
> > >>>>> of engineers give up their time and detecting and fixing this
> issue.
> > >>> 

Re: [DISCUSS] Blocking merge button in PR

[Nabarun Nag]

Owen ,
Or any other developers *please do not push directly to Apache Geode
develop code base without creating a pull request, asking for reviews and
testing the code*.

To rephrase, what you are saying is that now developers, in order to avoid
reviews and testing their code, will now push directly to develop. I don't
think anyone will be that sinister.

There is no harm in asking for reviews for even trivial things like docs
and tools. A second pair of eyes will not cause extra harm.

I will try getting the infra ticket created by EOD.

Regards
Naba



On Tue, Oct 22, 2019 at 9:53 AM Owen Nichols  wrote:

> This discussion has revolved around the assumption that all changes go
> through the PR process.
>
> If you’re a committer, nothing forces you to create a PR — you can also
> just commit directly to develop.  PRs are commonly used when the committer
> wants feedback (from the PR checks and/or from the community), while
> changes to docs and tools are sometimes made directly on develop.
>
> By making it harder to use the PR process, will this have the unintended
> side-effect of nudging more committers to skip it entirely?
>
>
>
> > On Oct 21, 2019, at 11:38 AM, Anthony Baker  wrote:
> >
> > +1, very well said
> >
> > Anthony
> >
> >> On Oct 21, 2019, at 11:05 AM, Nabarun Nag  wrote:
> >>
> >>
> >>
> >> *Reiterating the proposal:*
> >> Github branch protection rule for :
> >> - at least one review
> >> - Passing build, unit and stress test.
> >>
> >>
> >> In our opinion, no committer would want to check-in code with failing
> any
> >> of the above.
> >>
> >> Regards
> >> Nabarun
> >
>
>

[REQUEST] Squash merge please

[Nabarun Nag]

Hi Geode Committers,

A kind request for using squash commit instead of using merge.
This will really help us in our bisect operations when a
regression/flakiness in the product is introduced. We can automate and go
through fewer commits faster, avoiding commits like "spotless fix" and
"re-trigger precheck-in" or other minor commits in the merged branch.

Also, please use the commit format : (helps us to know who worked on it,
what is the history)



*GEODE-: 
* explanation line 1* explanation line 2*

This is not a rule or anything, but a request to help out your fellow
committers in quickly detecting a problem.

For inspiration, we can look into Apache Kafka / Spark where they have a
complete linear graph for their main branch HEAD [see attachment]

Regards
Naba.

Re: Please review PR #4188

[Nabarun Nag]

Hi Mario,

Please use the squash and merge button while merging PRs. This will help us
in detecting regression/flakiness failures faster.

A previous email stating why it was needed was sent to the dev list.

Regards
Naba


On Mon, Oct 21, 2019 at 11:05 PM Mario Ivanac  wrote:

> Hi,
>
> could somone review PR
>
> https://github.com/apache/geode/pull/4188
>
> for flaky test.
>
> Thanks,
> Mario
>

Fwd: [PSA] Github branch protection

[Nabarun Nag]

Hi, Geode dev Community,

This is an announcement that the GitHub branch protection rules are *now
active* on develop branch for Apache Geode.

The following rules are currently active :
- Require pull request reviews before merging - at least 1
- Require status checks to pass before merging
 [Only for
- concourse-ci/Build
   - concourse-ci/UnitTestOpenJDK11
   - concourse-ci/UnitTestOpenJDK8
   - concourse-ci/StressNewTestOpenJDK11]

After we stabilize the remaining test suites, we can add them to these rule
sets.

Also reminding the community to use squash merge while closing pull
requests.

Regards
Naba

Re: [PSA] Github branch protection

[Nabarun Nag]

@Aaron : which PR are you referring to? I can only see "GEODE-7326: Add
cache gets timers" which can be merged? I can get some more idea when I can
see whats going on.

Regards
Naba

@Kirk : let me run some experiments.

Regards
Naba


On Thu, Oct 24, 2019 at 2:57 PM Helena Bales  wrote:

> To Kirk's point, there is actually a way to dismiss requests for review.
> Info here:
>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review
> There's instructions in there for how to dismiss a request for changes. Not
> everyone can do that, so if you aren't a contributor yet you'll probably
> have to hit up a current contributor to get any requests for changes
> dismissed.
>
> On Thu, Oct 24, 2019 at 2:52 PM Kirk Lund  wrote:
>
> > One side effect is that any single request for changes will now
> completely
> > block merging the PR. I'm not certain this was intentional? One rogue
> > developer could block the merging of any or every PR. I'm not sure one
> > person should have that much power...
> >
> > On Thu, Oct 24, 2019 at 2:25 PM Nabarun Nag  wrote:
> >
> > > Hi, Geode dev Community,
> > >
> > > This is an announcement that the GitHub branch protection rules are
> *now
> > > active* on develop branch for Apache Geode.
> > >
> > > The following rules are currently active :
> > > - Require pull request reviews before merging - at least 1
> > > - Require status checks to pass before merging
> > >  [Only for
> > > - concourse-ci/Build
> > >- concourse-ci/UnitTestOpenJDK11
> > >- concourse-ci/UnitTestOpenJDK8
> > >- concourse-ci/StressNewTestOpenJDK11]
> > >
> > > After we stabilize the remaining test suites, we can add them to these
> > rule
> > > sets.
> > >
> > > Also reminding the community to use squash merge while closing pull
> > > requests.
> > >
> > > Regards
> > > Naba
> > >
> >
>

Re: [PSA] Github branch protection

[Nabarun Nag]

Hi Aaron / Kirk,

Thank you for the update. As Owen has mentioned that if there is a change
request from someone with write permission to the branch, we should address
it, or request a re-review.
In the "rogue developer" case which Kirk mentioned, and I hope that this
does not happen in the Apache Geode community, -- Halena has mentioned that
a review can be dismissed.

Please do let me know if there are any more information requests.

Regards
Naba


On Thu, Oct 24, 2019 at 3:43 PM Aaron Lindsey  wrote:

> @Naba That's the one. It was approved shortly after I sent that message
> though. It should be reproducible by requesting changes on a PR with no
> other reviews.
>
> @Owen It's unclear to me whether "requesting changes" is the same thing as
> a -1 vote. I had previously discussed this with some other committers who
> were under the impression that they were not the same thing.
>
> @Helena Thanks! I didn't know that was possible.
>
> - Aaron
>
>
> On Thu, Oct 24, 2019 at 3:02 PM Nabarun Nag  wrote:
>
> > @Aaron : which PR are you referring to? I can only see "GEODE-7326: Add
> > cache gets timers" which can be merged? I can get some more idea when I
> can
> > see whats going on.
> >
> > Regards
> > Naba
> >
> > @Kirk : let me run some experiments.
> >
> > Regards
> > Naba
> >
> >
> > On Thu, Oct 24, 2019 at 2:57 PM Helena Bales  wrote:
> >
> > > To Kirk's point, there is actually a way to dismiss requests for
> review.
> > > Info here:
> > >
> > >
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review
> > > There's instructions in there for how to dismiss a request for changes.
> > Not
> > > everyone can do that, so if you aren't a contributor yet you'll
> probably
> > > have to hit up a current contributor to get any requests for changes
> > > dismissed.
> > >
> > > On Thu, Oct 24, 2019 at 2:52 PM Kirk Lund  wrote:
> > >
> > > > One side effect is that any single request for changes will now
> > > completely
> > > > block merging the PR. I'm not certain this was intentional? One rogue
> > > > developer could block the merging of any or every PR. I'm not sure
> one
> > > > person should have that much power...
> > > >
> > > > On Thu, Oct 24, 2019 at 2:25 PM Nabarun Nag  wrote:
> > > >
> > > > > Hi, Geode dev Community,
> > > > >
> > > > > This is an announcement that the GitHub branch protection rules are
> > > *now
> > > > > active* on develop branch for Apache Geode.
> > > > >
> > > > > The following rules are currently active :
> > > > > - Require pull request reviews before merging - at least 1
> > > > > - Require status checks to pass before merging
> > > > >  [Only for
> > > > > - concourse-ci/Build
> > > > >- concourse-ci/UnitTestOpenJDK11
> > > > >- concourse-ci/UnitTestOpenJDK8
> > > > >- concourse-ci/StressNewTestOpenJDK11]
> > > > >
> > > > > After we stabilize the remaining test suites, we can add them to
> > these
> > > > rule
> > > > > sets.
> > > > >
> > > > > Also reminding the community to use squash merge while closing pull
> > > > > requests.
> > > > >
> > > > > Regards
> > > > > Naba
> > > > >
> > > >
> > >
> >
>

Re: [PSA] Github branch protection

[Nabarun Nag]

Edit: Helena has mentioned that a review can be dismissed.

[spelling mistake]


On Thu, Oct 24, 2019 at 4:35 PM Nabarun Nag  wrote:

> Hi Aaron / Kirk,
>
> Thank you for the update. As Owen has mentioned that if there is a change
> request from someone with write permission to the branch, we should address
> it, or request a re-review.
> In the "rogue developer" case which Kirk mentioned, and I hope that this
> does not happen in the Apache Geode community, -- Halena has mentioned that
> a review can be dismissed.
>
> Please do let me know if there are any more information requests.
>
> Regards
> Naba
>
>
> On Thu, Oct 24, 2019 at 3:43 PM Aaron Lindsey  wrote:
>
>> @Naba That's the one. It was approved shortly after I sent that message
>> though. It should be reproducible by requesting changes on a PR with no
>> other reviews.
>>
>> @Owen It's unclear to me whether "requesting changes" is the same thing as
>> a -1 vote. I had previously discussed this with some other committers who
>> were under the impression that they were not the same thing.
>>
>> @Helena Thanks! I didn't know that was possible.
>>
>> - Aaron
>>
>>
>> On Thu, Oct 24, 2019 at 3:02 PM Nabarun Nag  wrote:
>>
>> > @Aaron : which PR are you referring to? I can only see "GEODE-7326: Add
>> > cache gets timers" which can be merged? I can get some more idea when I
>> can
>> > see whats going on.
>> >
>> > Regards
>> > Naba
>> >
>> > @Kirk : let me run some experiments.
>> >
>> > Regards
>> > Naba
>> >
>> >
>> > On Thu, Oct 24, 2019 at 2:57 PM Helena Bales  wrote:
>> >
>> > > To Kirk's point, there is actually a way to dismiss requests for
>> review.
>> > > Info here:
>> > >
>> > >
>> >
>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review
>> > > There's instructions in there for how to dismiss a request for
>> changes.
>> > Not
>> > > everyone can do that, so if you aren't a contributor yet you'll
>> probably
>> > > have to hit up a current contributor to get any requests for changes
>> > > dismissed.
>> > >
>> > > On Thu, Oct 24, 2019 at 2:52 PM Kirk Lund  wrote:
>> > >
>> > > > One side effect is that any single request for changes will now
>> > > completely
>> > > > block merging the PR. I'm not certain this was intentional? One
>> rogue
>> > > > developer could block the merging of any or every PR. I'm not sure
>> one
>> > > > person should have that much power...
>> > > >
>> > > > On Thu, Oct 24, 2019 at 2:25 PM Nabarun Nag 
>> wrote:
>> > > >
>> > > > > Hi, Geode dev Community,
>> > > > >
>> > > > > This is an announcement that the GitHub branch protection rules
>> are
>> > > *now
>> > > > > active* on develop branch for Apache Geode.
>> > > > >
>> > > > > The following rules are currently active :
>> > > > > - Require pull request reviews before merging - at least 1
>> > > > > - Require status checks to pass before merging
>> > > > >  [Only for
>> > > > > - concourse-ci/Build
>> > > > >- concourse-ci/UnitTestOpenJDK11
>> > > > >- concourse-ci/UnitTestOpenJDK8
>> > > > >- concourse-ci/StressNewTestOpenJDK11]
>> > > > >
>> > > > > After we stabilize the remaining test suites, we can add them to
>> > these
>> > > > rule
>> > > > > sets.
>> > > > >
>> > > > > Also reminding the community to use squash merge while closing
>> pull
>> > > > > requests.
>> > > > >
>> > > > > Regards
>> > > > > Naba
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] Tweak to branch protection rules

[Nabarun Nag]

+1

On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider 
wrote:

> +1
>
> On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols  wrote:
>
> > +1 …this has already bitten me a few times
> >
> > > On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> > >
> > > Hi all,
> > >
> > > It seems we've configured our branch protection rules such that
> pushing a
> > > change to a PR that has been approved invalidates the previous
> approval.
> > >
> > > I think we should turn this off - it looks like it's an optional
> feature.
> > > We should trust people to rerequest reviews if needed. Right now this
> is
> > > adding busywork for people to reapprove minor changes (Fixing merge
> > > conflicts, spotless, etc.)
> > >
> > > If you all agree I'll ask infra to uncheck "Dismiss stale pull request
> > > approvals when new commits are pushed." in our branch protection rules.
> > >
> > > -Dan
> >
> >
>

Re: [DISCUSS] Tweak to branch protection rules

[Nabarun Nag]

The check box Dan is mentioning will just not invalidate any approved
review if the code is changed.
If a change is requested, the button will remain disabled.

Regards
Naba


On Wed, Oct 30, 2019 at 6:27 AM Joris Melchior  wrote:

> +1
>
> On Wed, Oct 30, 2019 at 5:27 AM Ju@N  wrote:
>
> > Question: this only applies for *approvals*, not for *refusals*, right?;
> I
> > mean, the *merge pull request* button will remain blocked if there were
> > some changes requested by reviewers and the author of the PR adds new
> > commits (either addressing those requested changes or not)?.
> > If the answer to the above is "yes", then +1.
> >
> > On Wed, Oct 30, 2019 at 1:44 AM Nabarun Nag  wrote:
> >
> > > +1
> > >
> > > On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider <
> dschnei...@pivotal.io>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols 
> > > wrote:
> > > >
> > > > > +1 …this has already bitten me a few times
> > > > >
> > > > > > On Oct 29, 2019, at 6:01 PM, Dan Smith 
> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > It seems we've configured our branch protection rules such that
> > > > pushing a
> > > > > > change to a PR that has been approved invalidates the previous
> > > > approval.
> > > > > >
> > > > > > I think we should turn this off - it looks like it's an optional
> > > > feature.
> > > > > > We should trust people to rerequest reviews if needed. Right now
> > this
> > > > is
> > > > > > adding busywork for people to reapprove minor changes (Fixing
> merge
> > > > > > conflicts, spotless, etc.)
> > > > > >
> > > > > > If you all agree I'll ask infra to uncheck "Dismiss stale pull
> > > request
> > > > > > approvals when new commits are pushed." in our branch protection
> > > rules.
> > > > > >
> > > > > > -Dan
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Ju@N
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Nabarun Nag]

@Aaron
It's okay to wait for at least the build, and unit tests to complete, to
cover all the bases. [There may have been commits in between which may
result in failure because of the revert]  And it's not hard to get a PR
approval.

-1 on overriding. If the infrastructure is down, which is the test
framework designed to ensure that we are not checking in unwanted changes
into Apache Geode, wait for the infrastructure to be up, get your changes
verified, get the review from a fellow committer and then check-in your
changes.

I still don't understand why will anyone not wait for unit tests and build
to be successful.

Regards
Nabarun Nag

On Wed, Oct 30, 2019 at 11:32 AM Aaron Lindsey  wrote:

> One case when it might be acceptable to overrule a PR check is reverting a
> commit. Before the branch protection was enabled, a committer could revert
> a commit without a PR. Now that PRs are mandatory, we have to wait for the
> checks to run in order to revert a commit. Usually we are reverting a
> commit because it's causing problems, so I think overruling the PR checks
> may be acceptable in that case.
>
> - Aaron
>
>
> On Wed, Oct 30, 2019 at 11:11 AM Owen Nichols  wrote:
>
> > Our new branch-protection rules can sometimes lead to unexpected
> obstacles
> > when infrastructure issues impede the intended process.  Should we
> discuss
> > such cases as they come up, and should overruling the result of a PR
> check
> > ever be an option on the table?
> >
> > -Owen
>

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

[Nabarun Nag]

Hi Udo

+1,
5.2.0.RELEASE to be specific?

On Wed, Oct 30, 2019 at 11:04 AM Ju@N  wrote:

> Hello Udo,
>
> Big +1 for the proposal!.
> That said, I believe it was agreed a couple of months ago in the
> *Lightweight
> RFC Process [1] *that the whole discussion should be done in the [DISCUSS]
> email thread directly and not as comments within the proposal itself, you
> might want to double check that and reply to the thread so the entire
> discussion remains in one single place.
> Cheers.
>
> [1]:
> https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process
>
> On Wed, Oct 30, 2019 at 5:54 PM Udo Kohlmeyer  wrote:
>
> > Hi there fellow Apache Geode Devs,
> >
> > We would like to propose the upgrade of the Spring libraries within
> > Geode Project.
> >
> > Currently the project is using Spring 4, which is EOL Q1 2020.
> >
> > The link the proposal can be found here
> > <
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+-+Upgrade+Spring+version+from+Spring+4+to+Spring+5.x
> >.
> >
> >
> >
> > Please provide feedback on this proposal as comments on the proposal's
> > comment section within Apache Geode wiki. Feedback will closed on 8
> > November 2019.
> >
> > --Udo
> >
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+-+Upgrade+Spring+version+from+Spring+4+to+Spring+5.x
> >
> >
>
> --
> Ju@N
>

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

[Nabarun Nag]

Hi Udo,
Maven has the latest as 5.2.0.RELEASE as the latest version.  In the
Dependency.groovy file, we have been putting the full version number. Hence
I am guessing you are suggesting we put 5.2.0.RELEASE?

What about the status of the following dependencies?

'org.springframework.hateoas', name: 'spring-hateoas', version:
'0.25.0.RELEASE'
'org.springframework.ldap', name: 'spring-ldap-core', version:
'2.3.2.RELEASE'
'org.springframework.shell', name: 'spring-shell', version: '1.2.0.RELEASE'

Regards
Naba

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

[Nabarun Nag]

Will breaking this PR into parts help. Put the tests in separate PRs?

+1 if it is inconvenient

On Thu, Oct 31, 2019 at 2:52 PM Donal Evans  wrote:

> +1 to allowing this PR to be merged, although I'd lean strongly toward
> facilitating this by temporarily increasing the timeout on the job to allow
> it to actually pass rather than a manual override of the StressNewTest.
>
> The fact that it's passed over 7000 times without failing is pretty strong
> evidence that it's not a flaky test, which is what StressNewTest is
> supposed to catch, so there doesn't seem to be any risk associated with
> circumventing it in this case, but if there's a feasible solution that
> doesn't involve "cheating" or ignoring the test job, then that would be
> preferable.
>
> - Donal
>
> On Thu, Oct 31, 2019 at 2:04 PM Jason Huynh  wrote:
>
> > Greetings,
> >
> > We have a pull request (https://github.com/apache/geode/pull/4250) that
> is
> > running into a problem with stressNewTest.  Mostly the tests that are
> being
> > run are RollingUpgrade tests that take quite a bit of time to run the
> full
> > suite.  Because these tests are added/modified, the stressNewTest doesn't
> > have enough time to complete the run because it runs them N(50) number of
> > times.
> >
> > However what has completed is 7400 tests and none of them have failed:
> >
> >
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4250/test-results/repeatTest/1572546653/
> >
> > We would like to get this fix in before branching the next release, but
> are
> > unable to due to stressNewTest gating the merge button.  I know we have
> > another thread about overrides etc, and maybe this is a data point, but
> > this isn't meant to discuss that.
> >
> > Would everyone be able to agree to allow someone to manually override and
> > merge this commit in (title of PR and reviews pending)?
> >
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Nabarun Nag]

ermined?
> > >>>>>
> > >>>>> On Wed, Oct 30, 2019 at 1:59 PM Owen Nichols 
> > >>>> wrote:
> > >>>>>>> How do you override a check, anyway?
> > >>>>>> Much like asking for jira permissions, wiki permissions, etc, just
> > >>> ask
> > >>>> on
> > >>>>>> the dev list ;)
> > >>>>>>
> > >>>>>> Presumably this type of request would be made as a “last resort”
> > >>>>> following
> > >>>>>> a dev list discussion wherein all other reasonable options had
> been
> > >>>>>> exhausted (reworking or splitting up the PR, pushing empty
> commits,
> > >>>>>> rebasing the PR, etc)
> > >>>>>>
> > >>>>>>> On Oct 30, 2019, at 1:42 PM, Dan Smith 
> wrote:
> > >>>>>>>
> > >>>>>>> +1 for allowing overrides. I think we should avoid backing
> > >>> ourselves
> > >>>>>> into a
> > >>>>>>> corner where we can't get anything into develop without talking
> to
> > >>>>> apache
> > >>>>>>> infra. Some infrastructure things we can't even fix without
> > >>> pushing a
> > >>>>>>> change develop!
> > >>>>>>>
> > >>>>>>> How do you override a check, anyway?
> > >>>>>>>
> > >>>>>>> -Dan
> > >>>>>>>
> > >>>>>>> On Wed, Oct 30, 2019 at 12:58 PM Donal Evans  >
> > >>>>> wrote:
> > >>>>>>>> -1 to overriding from me.
> > >>>>>>>>
> > >>>>>>>> The question I have here is what's the rush? Is anything ever so
> > >>>>>>>> time-sensitive that you can't even wait the 15 minutes it takes
> > >>> for
> > >>>> it
> > >>>>>> to
> > >>>>>>>> build and run unit tests? If some infrastructure problem is
> > >>>> preventing
> > >>>>>>>> builds or tests from completing then that should be fixed before
> > >>> any
> > >>>>> new
> > >>>>>>>> changes are added, otherwise what's the point in even having the
> > >>> pre
> > >>>>>>>> check-in process?
> > >>>>>>>>
> > >>>>>>>> -Donal
> > >>>>>>>>
> > >>>>>>>> On Wed, Oct 30, 2019 at 11:44 AM Nabarun Nag 
> > >>>> wrote:
> > >>>>>>>>> @Aaron
> > >>>>>>>>> It's okay to wait for at least the build, and unit tests to
> > >>>> complete,
> > >>>>>> to
> > >>>>>>>>> cover all the bases. [There may have been commits in between
> > >>> which
> > >>>>> may
> > >>>>>>>>> result in failure because of the revert]  And it's not hard to
> > >>> get
> > >>>> a
> > >>>>> PR
> > >>>>>>>>> approval.
> > >>>>>>>>>
> > >>>>>>>>> -1 on overriding. If the infrastructure is down, which is the
> > >>> test
> > >>>>>>>>> framework designed to ensure that we are not checking in
> unwanted
> > >>>>>> changes
> > >>>>>>>>> into Apache Geode, wait for the infrastructure to be up, get
> your
> > >>>>>> changes
> > >>>>>>>>> verified, get the review from a fellow committer and then
> > >>> check-in
> > >>>>> your
> > >>>>>>>>> changes.
> > >>>>>>>>>
> > >>>>>>>>> I still don't understand why will anyone not wait for unit
> tests
> > >>>> and
> > >>>>>>>> build
> > >>>>>>>>> to be successful.
> > >>>>>>>>>
> > >>>>>>>>> Regards
> > >>>>>>>>> Nabarun Nag
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Oct 30, 2019 at 11:32 AM Aaron Lindsey <
> > >>>> alind...@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> One case when it might be acceptable to overrule a PR check is
> > >>>>>>>> reverting
> > >>>>>>>>> a
> > >>>>>>>>>> commit. Before the branch protection was enabled, a committer
> > >>>> could
> > >>>>>>>>> revert
> > >>>>>>>>>> a commit without a PR. Now that PRs are mandatory, we have to
> > >>> wait
> > >>>>> for
> > >>>>>>>>> the
> > >>>>>>>>>> checks to run in order to revert a commit. Usually we are
> > >>>> reverting
> > >>>>> a
> > >>>>>>>>>> commit because it's causing problems, so I think overruling
> the
> > >>> PR
> > >>>>>>>> checks
> > >>>>>>>>>> may be acceptable in that case.
> > >>>>>>>>>>
> > >>>>>>>>>> - Aaron
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Oct 30, 2019 at 11:11 AM Owen Nichols <
> > >>>> onich...@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>> Our new branch-protection rules can sometimes lead to
> > >>> unexpected
> > >>>>>>>>>> obstacles
> > >>>>>>>>>>> when infrastructure issues impede the intended process.
> Should
> > >>>> we
> > >>>>>>>>>> discuss
> > >>>>>>>>>>> such cases as they come up, and should overruling the result
> > >>> of a
> > >>>>> PR
> > >>>>>>>>>> check
> > >>>>>>>>>>> ever be an option on the table?
> > >>>>>>>>>>>
> > >>>>>>>>>>> -Owen
> > >>>>>>
> > >>>
> > >>> --
> > >>> Ju@N
> > >>>
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: unable to push

[Nabarun Nag]

Hi Bruce,

This was what was discussed in multiple email chains last week. GitHub
branch protection was enabled on the develop branch.

Command-line and the merge button on the website have the same effect. This
has now being implemented in a lot of Apache projects and we are
implementing it as the geode community is growing, to prevent unintentional
red pipelines.

It is a small inconvenience paid for saving a lot of our time in detecting
which commit caused the red pipeline or which commit introduced a flaky
test. Our time can be used in other productive work.

Kindly reconsider as a majority of us have already moved to the GitHub
merge system on the website.

Regards
Nabarun



On Thu, Oct 31, 2019 at 4:45 PM Robert Houghton 
wrote:

> Was there a pull request for this SHA?
>
> On Thu, Oct 31, 2019, 16:36 Bruce Schuchardt 
> wrote:
>
> > I just completed GEODE-7358 and was prevented from pushing from the
> > command-line.  The Merge button on github worked, but why can't I have
> > command-line control of the process?  I don't like giving control of my
> > merge to a web-site button.  We should revert this change!
> >
> >
> > geode> git push --no-verify origin develop
> > Enumerating objects: 352, done.
> > Counting objects: 100% (352/352), done.
> > Delta compression using up to 8 threads
> > Compressing objects: 100% (192/192), done.
> > Writing objects: 100% (223/223), 153.60 KiB | 9.04 MiB/s, done.
> > Total 223 (delta 106), reused 59 (delta 3)
> > remote: Resolving deltas: 100% (106/106), completed with 93 local
> objects.
> > remote: error: GH006: Protected branch update failed for
> > refs/heads/develop.
> > remote: error: 4 of 4 required status checks are expected. At least 1
> > approving review is required by reviewers with write access.
> > To ssh://github.com/apache/geode.git
> >   ! [remote rejected]   develop -> develop (protected branch hook
> > declined)
> > error: failed to push some refs to 'ssh://
> g...@github.com/apache/geode.git'
> >
> >
>

Re: Re: unable to push

[Nabarun Nag]

It is how Github branch protection is designed.

This is my explanation from the information provided by you :

- The Pull Request you mentioned had 11 commits and when you tried to
merged it, I assume you tried to squash it to a single commit. It generates
a new SHA.
- When you are pushing that SHA to origin develop, GitHub could not find
that SHA in the list of approved Pull Requests SHAs.
- This is why it blocked your push to develop origin.

Workaround:
- This would have worked if there was only one commit in the Pull Request:
- If you still need to use the command line, you can create the Pull
Request with only one commit (after squashing).
- I generally, commit --amend over the last commit SHA and then force push,
so that it stays as a single commit.

Regards
Naba


On Thu, Oct 31, 2019 at 6:56 PM Bruce Schuchardt 
wrote:

> I just want to know why my PR that passed the tests and was approved
> couldn't be pushed from the command line Naba
>
> On 10/31/19 5:11 PM, Nabarun Nag wrote:
> > Hi Bruce,
> >
> > This was what was discussed in multiple email chains last week. GitHub
> > branch protection was enabled on the develop branch.
> >
> > Command-line and the merge button on the website have the same effect.
> > This
> > has now being implemented in a lot of Apache projects and we are
> > implementing it as the geode community is growing, to prevent
> > unintentional
> > red pipelines.
> >
> > It is a small inconvenience paid for saving a lot of our time in
> detecting
> > which commit caused the red pipeline or which commit introduced a flaky
> > test. Our time can be used in other productive work.
> >
> > Kindly reconsider as a majority of us have already moved to the GitHub
> > merge system on the website.
> >
> > Regards
> > Nabarun
> >
> >
> >
> > On Thu, Oct 31, 2019 at 4:45 PM Robert Houghton 
> > wrote:
> >
> >> Was there a pull request for this SHA?
> >>
> >> On Thu, Oct 31, 2019, 16:36 Bruce Schuchardt 
> >> wrote:
> >>
> >>> I just completed GEODE-7358 and was prevented from pushing from the
> >>> command-line. The Merge button on github worked, but why can't I have
> >>> command-line control of the process? I don't like giving control of my
> >>> merge to a web-site button. We should revert this change!
> >>>
> >>>
> >>> geode> git push --no-verify origin develop
> >>> Enumerating objects: 352, done.
> >>> Counting objects: 100% (352/352), done.
> >>> Delta compression using up to 8 threads
> >>> Compressing objects: 100% (192/192), done.
> >>> Writing objects: 100% (223/223), 153.60 KiB | 9.04 MiB/s, done.
> >>> Total 223 (delta 106), reused 59 (delta 3)
> >>> remote: Resolving deltas: 100% (106/106), completed with 93 local
> >> objects.
> >>> remote: error: GH006: Protected branch update failed for
> >>> refs/heads/develop.
> >>> remote: error: 4 of 4 required status checks are expected. At least 1
> >>> approving review is required by reviewers with write access.
> >>> To ssh://github.com/apache/geode.git
> >>> ! [remote rejected] develop -> develop (protected branch hook
> >>> declined)
> >>> error: failed to push some refs to 'ssh://
> >> g...@github.com/apache/geode.git'
> >>>
>

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

[Nabarun Nag]

Initial attempts have been made : https://github.com/apache/geode/pull/4256
This PR has Maintainers edit permissions enabled.

We need to figure out a plan on these following springframework
dependencies too.
- spring-hateos [geode - 0.25.0 RELEASE  latest 1.0.1 RELEASE]
- spring-plugin-core [geode - 1.2.0 RELEASE latest 2.0.0 RELEASE]
- spring-plugin-metadata [geode - 1.2.0 RELEASE latest 2.0.0 RELEASE]




On Thu, Nov 7, 2019 at 2:43 PM Jason Huynh  wrote:

> +1
>
> On Thu, Nov 7, 2019 at 1:28 PM Dan Smith  wrote:
>
> > +1
> >
> > On Thu, Nov 7, 2019 at 12:49 PM Jens Deppe  wrote:
> >
> > > +1
> > >
> > > On Wed, Oct 30, 2019 at 1:39 PM Udo Kohlmeyer  wrote:
> > >
> > > > Sorry,
> > > >
> > > > To clarify... When we change the Spring version we would be looking
> at
> > > > looking to use the latest version and it's associated BOM.
> > > >
> > > > That might be inclusive of other Spring project upgrades.
> > > >
> > > > --Udo
> > > >
> > > > On 10/30/19 1:35 PM, Nabarun Nag wrote:
> > > > > Hi Udo,
> > > > > Maven has the latest as 5.2.0.RELEASE as the latest version.  In
> the
> > > > > Dependency.groovy file, we have been putting the full version
> number.
> > > > Hence
> > > > > I am guessing you are suggesting we put 5.2.0.RELEASE?
> > > > >
> > > > > What about the status of the following dependencies?
> > > > >
> > > > > 'org.springframework.hateoas', name: 'spring-hateoas', version:
> > > > > '0.25.0.RELEASE'
> > > > > 'org.springframework.ldap', name: 'spring-ldap-core', version:
> > > > > '2.3.2.RELEASE'
> > > > > 'org.springframework.shell', name: 'spring-shell', version:
> > > > '1.2.0.RELEASE'
> > > > >
> > > > > Regards
> > > > > Naba
> > > > >
> > > >
> > >
> >
>

Re: Odg: gateway sender queue

[Nabarun Nag]

+1 to Dan's suggestion

What about a log and a vsd stat in the gfs file which tells us if any
cleanQueue commands were executed.


Regards
Nabarun Nag

On Thu, Nov 14, 2019 at 10:27 AM Udo Kohlmeyer  wrote:

> In addition... making is default has bigger consequences that we have
> not thought about..
>
> e.g if you purge an existing queue on start up.. is this the start up of
> the server node / GS Queue? Given that we have shared-nothing
> architecture, purging *should* only be local and not cluster-wide... I'd
> be interested and see a proposal on this feature.
>
> --Udo
>
> On 11/14/19 10:24 AM, Jason Huynh wrote:
> > +1 to Dan's suggestion
> >
> > On Thu, Nov 14, 2019 at 9:52 AM Dan Smith  wrote:
> >
> >> I'm ok with adding a --cleanQueue option.
> >>
> >> However, I don't think it should default to be true, since that would be
> >> changing the behavior of the existing command. It should default to
> false.
> >>
> >> -Dan
> >>
> >> On Thu, Nov 14, 2019 at 9:28 AM Xiaojian Zhou  wrote:
> >>
> >>> The --cleanQueue option is a similar idea as Barry's "DeadLetter"
> spike.
> >> I
> >>> remembered that we decided not to do it.
> >>>
> >>>
> >>> On Wed, Nov 13, 2019 at 11:41 PM Mario Ivanac 
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> just to remind you on last question:
> >>>>
> >>>> what is your opinion on adding additional option in gfsh command
> >> "start
> >>>> gateway sender"
> >>>> to control clearing of existing queues --cleanQueues.
> >>>>
> >>>> This option will indicate, when gateway sender is started, should we
> >>>> discard/clean existing queue, or should we use existing queue.
> >>>> By default it will be to discard/clean existing queue.
> >>>>
> >>>> Best Regards,
> >>>> Mario
> >>>> 
> >>>> Šalje: Mario Ivanac 
> >>>> Poslano: 8. studenog 2019. 13:00
> >>>> Prima: dev@geode.apache.org 
> >>>> Predmet: Odg: gateway sender queue
> >>>>
> >>>> Hi all,
> >>>>
> >>>> one more clarification regarding 3rd question:
> >>>>
> >>>> "*   Could we add extra option in gfsh command  "start gateway sender"
> >>>>   that allows to control queues reset (for instance
> --cleanQueues)"
> >>>>
> >>>> This option will indicate, when gateway sender is started, should we
> >>>> discard/clean existing queue, or should we use existing queue.
> >>>> By default it will be to discard/clean existing queue.
> >>>>
> >>>> Best Regards,
> >>>> Mario
> >>>> 
> >>>> Šalje: Mario Ivanac 
> >>>> Poslano: 7. studenog 2019. 9:01
> >>>> Prima: Dan Smith ; dev@geode.apache.org <
> >>>> dev@geode.apache.org>
> >>>> Predmet: Odg: gateway sender queue
> >>>>
> >>>> Hi,
> >>>>
> >>>> thanks for answers.
> >>>>
> >>>> Some more details regarding 1st question.
> >>>>
> >>>> Is this behavior same (for serial and parallel gateway sender) in case
> >>>> queue is persistent?
> >>>> Meaning, should queue (persistent) be purged if we restart gateway
> >>> sender?
> >>>>
> >>>> Thanks,
> >>>> Mario
> >>>>
> >>>> 
> >>>> Šalje: Dan Smith 
> >>>> Poslano: 5. studenog 2019. 18:52
> >>>> Prima: dev@geode.apache.org 
> >>>> Predmet: Re: gateway sender queue
> >>>>
> >>>> Some replies, inline:
> >>>>
> >>>>*   During testing we have observed, different behavior in parallel
> >> and
> >>>>> serial gateway senders. In case we manually stop, than start gateway
> >>>>> senders, for parallel gateway senders, queue is purged, but for
> >> serial
> >>>>> gateway senders this is not the case. Is this normal behavior or bug?
> >>>>>
> >>>> Hmm, I also think stop is supposed to clear the queue. I think if you
> >> are
> >>>> seeing that it doesn't clear the queue, that might be a bug.
> >>>>
> >>>>
> >>>>
> >>>>>*   What happens with the queues when whole cluster is stopped and
> >>>> later
> >>>>> started (In our tests with persistent queues, the events are kept)?
> >>>>>
> >>>> Persistent queues will keep all of the events when you restart.
> >>>>
> >>>>
> >>>>>*   Could we add extra option in gfsh command  "start gateway
> >> sender"
> >>>>> that allows to control queues reset (for instance --cleanQueues)?
> >>>>>
> >>>> If stop does clear the queue, would this be needed? It might still be
> >>>> reasonable - I've heard folks request a way to clear running queues as
> >>>> well.
> >>>>
> >>>> -Dan
> >>>>
>

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

[Nabarun Nag]

+1

On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  wrote:

> Thank you for this Bill,
>
> I must admit that I'm starting to get a feeling of "scope creep" here..
> I understand that all efforts to "modularize" membership would require
> some form of peripheral decoupling.
>
> BUT
>
> I'm starting to get concerned that we are hitting a rabbit hole
> scenario. Maybe this is normal for an effort of this manner, BUT, I
> would like to urge that we start discussing/proposing other
> modulizations, like, Serialization and now TCP communications as real
> modules with own proposals and with their own merit.
>
> YES, I understand this is minimal touch modulizations, but I'm concerned
> that we are doing work under the incorrect banner. Just enough to
> complete one "piece of it", but possibly a rework, of the module because
> of the "good enough" approach we take.
>
> Maybe we are discovering that there is some pre-work that needed to have
> been completed before the whole membership modularization effort was
> started.. And maybe this is the time where we need to take a step back,
> look at this from a higher perspective and decide if membership is
> really still the priority here with serialization and transport
> (TCPServer) being a side-effect.
>
> For this reason alone I vote: *-0 *on this matter.. (it is only a little
> better than -1)
>
> --Udo
>
> On 11/18/19 1:48 PM, Bill Burcham wrote:
> > Dear Geode,
> >
> > In support of the Membership modularization efforts
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> ,
> > we would like to move the types in the
> > org.apache.geode.distributed.internal.tcpserver package (i.e. the
> TcpServer
> > class and related types) into a separate module in order to eliminate
> > dependencies on geode-core.
> >
> > The membership subsystem is dependent on this group of types, which in
> turn
> > are (were) highly-dependent on geode-core. We have been systematically
> > eliminating dependencies from these types to geode-core as part of
> > https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> > depend on geode-core_ The final sub-task on that ticket puts TcpServer
> and
> > related types into its own separate module.
> >
> > The proposed module would be called "geode-tcp-server" and would contain
> > TcpServer and the other types in the
> > org.apache.geode.distributed.internal.tcpserver package.
> >
> > Your feedback is welcomed and appreciated.
> >
> > Your Friend,
> > Bill
> >
>

Re: [VOTE] Fix bad-merge of GEODE-7488

[Nabarun Nag]

+1

On Fri, Nov 22, 2019 at 12:00 PM Anthony Baker  wrote:

> Clearly the right thing to do is fix it.  VOTE not needed IMO.
>
> Anthony
>
>
> > On Nov 22, 2019, at 11:55 AM, Robert Houghton 
> wrote:
> >
> > I was overzealous in a merge to Geode, and got us into a chicken-and-egg
> > issue for PRs and reverts. Calling a vote to override the GitHub merge
> > button restriction via commiter privileges, to merge the fix in
> > https://github.com/apache/geode/pull/4360
>
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Nabarun Nag]

Just out of curiosity, why did the PR checks for GEODE-7488 not fail and
allowed it be merged? Is something lacking in our testing?

On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:

> On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:
>
> > Tallying the votes from this thread, it looks like the majority vote is
> to
> > NEVER allow override even in extreme circumstance.
> >
>
> I think a better way of summarizing this thread so far is that there isn't
> really a consensus on this point, opinions seem to be fairly split. This
> wasn't a vote, and not everybody who expressed an opinion put a number next
> to their opinion or was directly aligned with the statement above.
>
> Maybe folks who think there should not be an override option could propose
> a specific process for dealing with issues like what Robert just did and
> try to bring the rest of us on board with that?
>
> -Dan
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Nabarun Nag]

+1

On Fri, Nov 22, 2019 at 12:51 PM Charlie Black  wrote:

> this proposal == awesome sauce
>
> +1
>
> On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton 
> wrote:
>
> > +1
> >
> > Do we want to restart from my lazy POC from a few months ago?
> >
> > On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:
> >
> > > Hello All,
> > >
> > > We'd like to propose moving gfsh and all associated commands into its
> own
> > > gradle submodule (implicitly thus also producing a separate maven
> > > artifact). The underlying intent is to decouple geode core from any
> > Spring
> > > dependencies.
> > >
> > > The proposal is outlined here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > >
> > > Please provide feedback for this proposal *on this email thread* and
> not
> > in
> > > the comment section of the proposal page.
> > >
> > > The deadline for this proposal will be Monday, December 2.
> > >
> > > Thanks in advance for feedback / comments.
> > >
> > > --Jens & Patrick
> > >
> >
>
>
> --
> Charlie Black | cbl...@pivotal.io
>

Re: [REQUEST] Squash merge please

[Nabarun Nag]

It is to help with bisect operations when things start failing ... helps us
it revert and build faster.
also with cherry picking features / fixes to previous versions .
And keeping the git history clean with no unnecessary “merge commits”.

Regards
Naba


On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund  wrote:

> -1 I really like to sometimes have more than 1 commit in a PR and keep them
> separate when they merge to develop
>
> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag  wrote:
>
> > Hi Geode Committers,
> >
> > A kind request for using squash commit instead of using merge.
> > This will really help us in our bisect operations when a
> > regression/flakiness in the product is introduced. We can automate and go
> > through fewer commits faster, avoiding commits like "spotless fix" and
> > "re-trigger precheck-in" or other minor commits in the merged branch.
> >
> > Also, please use the commit format : (helps us to know who worked on it,
> > what is the history)
> >
> >
> >
> > *GEODE-: 
> > * explanation line 1* explanation line 2*
> >
> > This is not a rule or anything, but a request to help out your fellow
> > committers in quickly detecting a problem.
> >
> > For inspiration, we can look into Apache Kafka / Spark where they have a
> > complete linear graph for their main branch HEAD [see attachment]
> >
> > Regards
> > Naba.
> >
> >
> >
>

Re: [REQUEST] Squash merge please

[Nabarun Nag]

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

Thank you for your feedback.

Regards
Naba


On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund  wrote:

> Whenever I submit a PR with multiple commits that I intend to rebase to
> develop, I always try to ensure that each commit stands alone as is
> (compiles and passes tests). Separating file renames and refactoring from
> behavior changes into different commits seems very valuable to me, and I've
> had trouble getting people to review PRs without this separation (but it
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some PRs have multiple commits
> that don't compile or don't pass tests, and (b) some PRs that should be
> merged with squash are not (by accident most likely).
>
> I can submit multiple PRs instead of one PR with multiple commits. So I'll
> change my response to -0 if that helps prevent commits to develop that
> don't compile or pass tests. Without preventing rebase or merge commits
> from github, I'm not sure how we can really enforce this or prevent (b)
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann 
> wrote:
>
> > I wonder if Kirk's and Naba's statements are necessarily at odds.
> >
> > Make the change easy (warning: this may be hard), then make the easy
> > > change."
> >
> >  -Kent Beck
> >
> > Following Kent Beck's advise might reasonably split into two commits. One
> > refactor commit and a separate commit that introduces the actual change.
> > They should be individually revertible and might be easier understood if
> > split out. I vividly remember a change on our code base where someone
> did a
> > huge amount of refactoring that resulted than in one parameter changing
> in
> > order to get the desired functionality change. If that was in one commit,
> > it would be hard to see the actual change. If split out, it's beautiful
> and
> > crystal clear.
> >
> > I am unsure how that would be reflected in terms of JIRA ticket
> references.
> > Usually we assume that if there is a commit with the ticket number, the
> > issue is resolved. Maybe the key here is to create a separate refactoring
> > ticket.
> >
> > Would that allow us to have our cake and eat it too?
> >
> > On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag  wrote:
> >
> > > It is to help with bisect operations when things start failing ...
> helps
> > us
> > > it revert and build faster.
> > > also with cherry picking features / fixes to previous versions .
> > > And keeping the git history clean with no unnecessary “merge commits”.
> > >
> > > Regards
> > > Naba
> > >
> > >
> > > On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund  wrote:
> > >
> > > > -1 I really like to sometimes have more than 1 commit in a PR and
> keep
> > > them
> > > > separate when they merge to develop
> > > >
> > > > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag  wrote:
> > > >
> > > > > Hi Geode Committers,
> > > > >
> > > > > A kind request for using squash commit instead of using merge.
> > > > > This will really help us in our bisect operations when a
> > > > > regression/flakiness in the product is introduced. We can automate
> > and
> > > go
> > > > > through fewer commits faster, avoiding commits like "spotless fix"
> > and
> > > > > "re-trigger precheck-in" or other minor commits in the merged
> branch.
> > > > >
> > > > > Also, please use the commit format : (helps us to know who worked
> on
> > > it,
> > > > > what is the history)
> > > > >
> > > > >
> > > > >
> > > > > *GEODE-: 
> > > > > * explanation line 1* explanation
> > line
> > > 2*
> > > > >
> > > > > This is not a rule or anything, but a request to help out your
> fellow
> > > > > committers in quickly detecting a problem.
> > > > >
> > > > > For inspiration, we can look into Apache Kafka / Spark where they
> > have
> > > a
> > > > > complete linear graph for their main branch HEAD [see attachment]
> > > > >
> > > > > Regards
> > > > > Naba.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [REQUEST] Squash merge please

[Nabarun Nag]

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


How many commits should be there in a PR can be placed in a different
discussion thread.

Regards
Naba



On Mon, Dec 16, 2019 at 10:02 AM Mark Hanson  wrote:

> I would strongly prefer smaller as small a commit as possible. And as
> large as necessary. I am less partial when it comes to PRs sizes. Sometimes
> depending on what is done in a PR, I don’t think it makes sense to issue a
> blanket statement that all PRs are one commit. I think there is a strong
> reason to make them one commit, but one size does not fit all. A great
> example is a refactor and a bug fix in one PR.
>
> Thanks,
> Mark
>
> > On Dec 16, 2019, at 9:47 AM, Kirk Lund  wrote:
> >
> > Whenever I submit a PR with multiple commits that I intend to rebase to
> > develop, I always try to ensure that each commit stands alone as is
> > (compiles and passes tests). Separating file renames and refactoring from
> > behavior changes into different commits seems very valuable to me, and
> I've
> > had trouble getting people to review PRs without this separation (but it
> > could be squashed as it's merged to develop).
> >
> > It sounds to me like the real problem is (a) some PRs have multiple
> commits
> > that don't compile or don't pass tests, and (b) some PRs that should be
> > merged with squash are not (by accident most likely).
> >
> > I can submit multiple PRs instead of one PR with multiple commits. So
> I'll
> > change my response to -0 if that helps prevent commits to develop that
> > don't compile or pass tests. Without preventing rebase or merge commits
> > from github, I'm not sure how we can really enforce this or prevent (b)
> > above.
> >
> > On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann 
> > wrote:
> >
> >> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>
> >> Make the change easy (warning: this may be hard), then make the easy
> >>> change."
> >>
> >> -Kent Beck
> >>
> >> Following Kent Beck's advise might reasonably split into two commits.
> One
> >> refactor commit and a separate commit that introduces the actual change.
> >> They should be individually revertible and might be easier understood if
> >> split out. I vividly remember a change on our code base where someone
> did a
> >> huge amount of refactoring that resulted than in one parameter changing
> in
> >> order to get the desired functionality change. If that was in one
> commit,
> >> it would be hard to see the actual change. If split out, it's beautiful
> and
> >> crystal clear.
> >>
> >> I am unsure how that would be reflected in terms of JIRA ticket
> references.
> >> Usually we assume that if there is a commit with the ticket number, the
> >> issue is resolved. Maybe the key here is to create a separate
> refactoring
> >> ticket.
> >>
> >> Would that allow us to have our cake and eat it too?
> >>
> >> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag  wrote:
> >>
> >>> It is to help with bisect operations when things start failing ...
> helps
> >> us
> >>> it revert and build faster.
> >>> also with cherry picking features / fixes to previous versions .
> >>> And keeping the git history clean with no unnecessary “merge commits”.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund  wrote:
> >>>
> >>>> -1 I really like to sometimes have more than 1 commit in a PR and keep
> >>> them
> >>>> separate when they merge to develop
> >>>>
> >>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag  wrote:
> >>>>
> >>>>> Hi Geode Committers,
> >>>>>
> >>>>> A kind request for using squash commit instead of using merge.
> >>>>> This will really help us in our bisect operations when a
> >>>>> regression/flakiness in the product is introduced. We can automate
> >> and
> >>> go
> >>>>> through fewer commits faster, avoiding commits like "spotless fix"
> >> and
> >>>>> "re-trigger precheck-in" or other minor commits in the merged branch.
> >>>>>
> >>>>> Also, please use the commit format : (helps us to know who worked on
> >>> it,
> >>>>> what is the history)
> >>>>>
> >>>>>
> >>>>>
> >>>>> *GEODE-: 
> >>>>> * explanation line 1* explanation
> >> line
> >>> 2*
> >>>>>
> >>>>> This is not a rule or anything, but a request to help out your fellow
> >>>>> committers in quickly detecting a problem.
> >>>>>
> >>>>> For inspiration, we can look into Apache Kafka / Spark where they
> >> have
> >>> a
> >>>>> complete linear graph for their main branch HEAD [see attachment]
> >>>>>
> >>>>> Regards
> >>>>> Naba.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

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

[Nabarun Nag]

ve existing wording in the wiki as-is [stating that squashing
> is
> >>>> preferred].
> >>>>
> >>>>
> >>>> Please comment via this email thread.
> >>>> -Owen
> >>>>
> >>>>
> >>>>
> >>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund  wrote:
> >>>>>
> >>>>> I think it's already resolved Udo ;)
> >>>>>
> >>>>> Here's the problem, if I fixup a dunit test by removing all uses of
> >>>> "this."
> >>>>> and I rename the dunit test, then git doesn't remember that the file
> >>> is a
> >>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>> created
> >>>>> if I touch more than 50% of the lines (which "this." can easily do).
> If
> >>>> we
> >>>>> squash two commits: the rename and the cleanup of that dunit test --
> >>> then
> >>>>> we effectively lose the history of that file and it shows that I
> >>> created
> >>>> a
> >>>>> new file.
> >>>>>
> >>>>> Also for the record, I've been working on Geode since the beginning
> >>> and I
> >>>>> was never made aware of this change in our process. I never voted on
> >>> it.
> >>>>> I'm not a big fan of changing various details in our process every
> >>> single
> >>>>> week. It's very easy to miss these discussions unless someone points
> it
> >>>> out
> >>>>> to me.
> >>>>>
> >>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> >>>>> wrote:
> >>>>>
> >>>>>> I'm not sure what this discussion is about... WE, as a community,
> have
> >>>>>> agreed in common practices, in two place no less...
> >>>>>>
> >>>>>> 1) Quoting our PR template
> >>>>>>
> >>>>>>
> >>>>>>For all changes:
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  Is there a JIRA ticket associated with this PR? Is it referenced in
> >>>>>>  the commit message?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  Has your PR been rebased against the latest commit within the
> >>> target
> >>>>>>  branch (typically|develop|)?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  ***Is your initial contribution a single, squashed commit?*
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  Does|gradlew build|run cleanly?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  Have you written or updated unit tests to verify your changes?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>>  If adding new dependencies to the code, are these dependencies
> >>>>>>  licensed in a way that is compatible for inclusion underASF 2.0
> >>>>>>  <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>
> >>>>>> On our PR template we call out that the initial PR commit should be
> >>>>>> squashed.
> >>>>>>
> >>>>>> 2)
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>> <
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>
> >>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>
> >>>>>>
> >>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
> >>>>>> diligence, but in reality, they should either then be stand alone
> PR's
> >>>>>> or just extra work created for yourself.
> >>>>>>
> >>>>>> If we want to change the way we have agreed upon we
> >>> submit/commit/merge
> >>>>>> changes back into develop... Then this is another d

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

[Nabarun Nag]

>>> on
> >>>>>>> develop should be linear (no merge commits), and that the biggest
> >>>>>> obstacle
> >>>>>>> to this is that the PR merge button in GitHub creates a merge
> commit
> >> by
> >>>>>>> default.
> >>>>>>>
> >>>>>>> I propose the following changes:
> >>>>>>> 1) Change GitHub settings to remove the ability to create a merge
> >> commit.
> >>>>>>> This will make Squash & Merge the default.
> >>>>>>>
> >>>>>>> 2) Change GitHub settings to require linear history on develop.
> This
> >>>>>>> prevents merge commits via command-line (not recommended, but wiki
> >> still
> >>>>>>> has instructions for merging PRs this way).
> >>>>>>>
> >>>>>>> 3) Update the PR template to change the text "Is your initial
> >>>>>> contribution
> >>>>>>> a single, squashed commit” to “Is your initial contribution
> squashed
> >> for
> >>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus
> >> a
> >>>>>>> ‘fix’ commit)"
> >>>>>>>
> >>>>>>> For clarity, I am proposing no-change in the following areas:
> >>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >> structured to
> >>>>>>> benefit from it (this can make it easier in a bisect to see whether
> >> the
> >>>>>>> refactoring or the “fix” broke something).
> >>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> squashing
> >> is
> >>>>>>> preferred].
> >>>>>>>
> >>>>>>>
> >>>>>>> Please comment via this email thread.
> >>>>>>> -Owen
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund  wrote:
> >>>>>>>>
> >>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>
> >>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
> of
> >>>>>>> "this."
> >>>>>>>> and I rename the dunit test, then git doesn't remember that the
> file
> >>>>>> is a
> >>>>>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>>>>> created
> >>>>>>>> if I touch more than 50% of the lines (which "this." can easily
> >> do). If
> >>>>>>> we
> >>>>>>>> squash two commits: the rename and the cleanup of that dunit test
> --
> >>>>>> then
> >>>>>>>> we effectively lose the history of that file and it shows that I
> >>>>>> created
> >>>>>>> a
> >>>>>>>> new file.
> >>>>>>>>
> >>>>>>>> Also for the record, I've been working on Geode since the
> beginning
> >>>>>> and I
> >>>>>>>> was never made aware of this change in our process. I never voted
> on
> >>>>>> it.
> >>>>>>>> I'm not a big fan of changing various details in our process every
> >>>>>> single
> >>>>>>>> week. It's very easy to miss these discussions unless someone
> >> points it
> >>>>>>> out
> >>>>>>>> to me.
> >>>>>>>>
> >>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >> ukohlme...@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
> >> have
> >>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>
> >>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>
> >>>>>>>>>
> >>>>>

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

[Nabarun Nag]

Just to reiterate. Nothing changes in the workflow of a developer. It's
just in the end, when all the reviews are done and all the tests are
passing, then the button to click in the Github web UI is "Squash and
Merge". That's all.

Regards
Naba



On Fri, Dec 20, 2019 at 11:55 AM Blake Bender  wrote:

> Very well, then, I'll abide by the group consensus but am on the record as:
> * strongly opposed to multi-commit PRs, because I believe it clutters
> history, and
> * also not a big fan of forcing devs to rebase and squash prior to
> submitting a PR.  IMO this is busy work, and *may* in some small minority
> of cases hide information that would be useful to reviewers.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker  wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender  wrote:
> > >
> > > Is this a policy the native client team must abide by, as well?  It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that.  If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets.  IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way.  We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburgha...@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen,  I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschucha...@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR.  This all seems out of order to
> > me.
> > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > >>> haven't
> > >>>> seen a VOTE reque

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

[Nabarun Nag]

Hi Dan,

When we do squash merge all the commit messages are preserved and also the
co-authored tag works when we do squash merge.
So the authorship and history are preserved.

In my own personal experience and reverts and pinpointing regression
failures are tough when the commits are spread out. Also, reverts are
easier when it is just one commit while we are bisecting failures.


Regards
Naba

On Fri, Dec 20, 2019 at 12:07 PM Dan Smith  wrote:

> I'll change to -0.
>
> I think merge commits are a nice way to record history in some cases, and
> can also be a way to avoid messy conflicts that come with rebase. Merge
> commits also preserve authorship of commits (compared to squash-merge),
> which I think is valuable as an open source community that is trying to
> keep track of outside contributions.
>
> That said, if the rest of y'all feel it will help to disable the button, I
> won't stand in the way.
>
> -Dan
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker  wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender  wrote:
> > >
> > > Is this a policy the native client team must abide by, as well?  It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that.  If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets.  IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way.  We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburgha...@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen,  I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschucha...@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR.  This all

Re: [DISCUSS] abandon branch protection rules

[Nabarun Nag]

Please maintain the branch protection rules.
Waiting for reviews and Unit tests to pass does not stifle productivity,
but prevents us from making mistakes that are detrimental to the entire
community. If I am not mistaken, we still have pushed code which broke
builds and regressions. I would suggest not removing but improving / add
ons to the checks to prevent such issues from happening again.

Also, personally I feel that CI code can separated out of geode code base
as they have no tests to run and they can circumvent the unit test pass
criteria.

I would just like to say that fixing tests is all of our responsibility,
not a particular group of developers.

Regards
Naba







On Fri, Dec 27, 2019 at 3:05 PM Jason Huynh  wrote:

> Just to add more flavor to my previous response... I currently have a PR
> open that modified a method signature that touched a few WAN tests.  It was
> a simple change, removing an unused parameter.  StressNewTest failed and I
> had to spend another day figuring out 10 or so different failures.  A waste
> of time?  Maybe..  At first, I wasn't going to continue, but after trying a
> few things, it looks like the tests installed a listener that was hampering
> other tests.  At the end (soon once it gets reviewed/merged), we end up
> with a Green PR and hopefully have unblocked others on these specific tests
> in the future.
>
> On Fri, Dec 27, 2019 at 2:58 PM Jason Huynh  wrote:
>
> > I feel the frustration at times, but I do also think the ci/pipelines are
> > improving, breaking less often.  I'm ok with the way things are for the
> > moment
> >
> > On Fri, Dec 27, 2019 at 1:47 PM Owen Nichols 
> wrote:
> >
> >> In October we agreed to require at least 1 reviewer and 4 passing PR
> >> checks before a PR can be merged.  Now that we’re tried it for a few
> >> months, do we like it?
> >>
> >> I saw some strong opinions on the dev list recently:
> >>
> >> > Changes to the infrastructure to flat out prevent things that should
> be
> >> self policing is annoying. This PR review lock we have had already cost
> us
> >> valuable time waiting for PR pipelines to pass that have no relevance to
> >> the commit, like CI work. I hate to see process enforced that keeps us
> from
> >> getting work done when necessary.
> >>
> >>
> >> and
> >>
> >> > I think we're getting more and more bureaucratic in our process and
> >> that it stifles productivity.  I was recently forced to spend three days
> >> fixing tests in which I had changed an import statement before they
> would
> >> pass stress testing.  I'm glad the tests now pass reliably but I was
> very
> >> frustrated by the process.
> >>
> >>
> >> Just wondering if others feel the same way.  Is it time to make some
> >> changes?
> >>
> >> -Owen
> >
> >
>

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

[Nabarun Nag]

+1 to Dan's suggestions.

- Remove in batches.
- Send review requests for those PRs to relevant committers (authors of
those tests etc.)
- A brief explanation on why these tests are being deleted, and there is no
loss of test coverage as it is covered by these other tests (or some other
reason).

Regards
Nabarun Nag

On Tue, Dec 31, 2019 at 5:32 PM Dan Smith  wrote:

> Some of these test have been ignored for a long time. However, looking at
> the history, I see we have ignored some tests as recently as in the last
> month, for what seem like some questionable reasons.
>
> I'm concerned that this could be a two step process to losing test coverage
> - someone who things the test is still valuable but intends to fix it later
> ignores it, and then someone else deletes it.
>
> So what I would suggest is that if we are going to delete them, let's do it
> in batches in get folks that have context on the code being tested to
> review the changes. Make sense?
>
> Also +1 to not ignoring any more tests - it would be nice to get down to 0
> Ignored tests and enforce that!
>
> -Dan
>
> On Tue, Dec 31, 2019 at 4:52 PM Aaron Lindsey 
> wrote:
>
> > I’m in favor of deleting all except the ones that have JIRA tickets open
> > for them, like Bruce said.
> >
> > Also going forward I’d like to see us not be checking in @Ignored tests —
> > just delete them instead. If we need to get it back we have revision
> > history. Just my two cents.
> >
> > Aaron
> >
> > > On Dec 31, 2019, at 2:53 PM, Bruce Schuchardt 
> > wrote:
> > >
> > > I agree with deleting @Ignored tests except for the few that have JIRA
> > tickets open for them.  There are less than 1/2 dozen of these and we
> > should consider keeping them since we have a way of tracking them.
> > >
> > > On 12/31/19 2:07 PM, Alexander Murmann 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
> > >>patterns buys us that much. I'd rather see something similar to
> what
> > some
> > >>folks are doing with Membership right now where we isolate the code
> > and
> > >>test it more systematically
> > >>- We have other testing gaps: We have benchmarks 👏🎉, but we are
> > still
> > >>lacking coverage in that ares; our community is still lacking HA
> > tests. I'd
> > >>rather fill those than bring back old DUnit tests that are chosen
> > somewhat
> > >>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. Let's make sure our tests carry their
> weight.
> > >>- If we delete these tests, we can always go back to a SHA from
> today
> > >>and bring them back at a later date
> > >>- These tests have been ignored since a very long time and we've
> > shipped
> > >>without them and nobody has missed them enough to bring them back.
> > >>
> > >> Given all the above, my vote is for less noise in our code, which
> means
> > >> deleting all ignored tests. If we want to keep them, I'd love to hear
> a
> > >> plan of action on how we bring them back. Having a bunch of dead code
> > helps
> > >> nobody.
> > >>
> > >> On Tue, Dec 31, 2019 at 1:50 PM Mark Hanson 
> wrote:
> > >>
> > >>> 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, but
> > those
> > >>> tests were written for a reason (I hope).  Or we could leave them.
> This
> > >>> pollutes searches etc as inactive code requiring upkeep at least.
> > >>>
> > >>> I don’t have an easy answer. Some have suggested deleting them. I
> tend
> > to
> > >>> lean that direction, but I thought I would consult the community for
> a
> > >>> broader perspective.
> > >>>
> > >>> Thanks,
> > >>> Mark
> >
> >
>

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

[Nabarun Nag]

>> are still other ways to get non-compiling commits onto develop (e.g.
> >>> waiting a long time between running PR checks and merging to develop).
> >>> What’s more important is working well together as a community. So,
> >> perhaps
> >>> what’s best for the community is to encourage working on trust rather
> >> than
> >>> unnecessary constraints.
> >>>
> >>> -Owen
> >>>
> >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund  wrote:
> >>>
> >>> I'm happy to file multiple PRs when I need to merge multiple commits to
> >>> develop.
> >>>
> >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson 
> wrote:
> >>>
> >>> 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:25 PM, Owen Nichols  wrote:
> >>>
> >>> Given that we adopted <
> >>>
> >>>
> >>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> >>>>
> >>> and still wish to continue <
> >>>
> >>
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> >>>>
> >>> having branch protection rules to ensure every commit landing in
> develop
> >>> has passed the required PR checks, it seems like that decision alone
> >>> mandates that we disable all merge mechanisms other than
> >> squash-and-merge.
> >>>
> >>>
> >>> Allowing merge commits or rebase merges bypasses branch protection for
> >>>
> >>> all commits other than the final one in the merge or rebase set.  Given
> >>> that we decided <
> >>>
> >>
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >>>>
> >>> that bypassing PR checks should never be allowed, keeping this loophole
> >>> open seems untenable.
> >>>
> >>>
> >>> This is not just hypothetical — this loophole is causing real problems.
> >>>
> >>> We now have commits on develop that don’t compile.  For example:
> >>>
> >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> >>> ./gradlew devBuild
> >>> ...spotlessJava FAILED
> >>> We implemented branch protections to make this impossible, right?
> >>>
> >>> We can very easily close this loophole by disabling all but the
> >>>
> >>> Squash&Merge button for PRs.  This will not make more work for any
> >>> developer.  If you want to get multiple commits onto develop, simply
> >> submit
> >>> each as a separate PR — that is the only way to assure that required PR
> >>> checks have passed for each.
> >>>
> >>>
> >>> On the other hand, if we as a Geode community feel strongly that
> >>>
> >>> bypassing branch protection via merge commits and rebase commits is
> >>> important to allow, why not also allow arbitrary overrides (or get rid
> of
> >>> branch protection entirely)?
> >>>
> >>>
> >>> -Owen
> >>>
> >>> On Dec 20, 2019, at 12:31 PM, Blake Bender  wrote:
> >>>
> >>> Just FWIW, the situation described of having multiple commits in a
> >>>
> >>> single
> >>>
> >>> PR with separate associated JIRA tickets is still kind of problematic.
> >>>
> >>> It
> >>>
> >>> could well be the case that the commits are interdependent, thus when
> >>> bisecting etc it's still not possible to revert the fix for a single
> >>> bug/feature/whatever atomically.  It's all good, though, I'm satisfied
> >>>
> >>> no
> >>>
> >>> one's forcing me to adopt practice I'm opposed to.  Apologies for
> >>>
> >>> getting
> >>>
> >>> my feathers a little ruffled, or if I ruffled anyone else's in return.
> 

Re: WAN replication issue in cloud native environments

[Nabarun Nag]

Hi Alberto,

Thank you for the contributions to the Apache Geode project

Here are a few feedback and pointers that we came up with:
1. Right now looking at your solution, we can see that you are modifying
the class "ServerLocation" which is used to stored as a key in the
connectionMap in LocatorLoadSnapshot.
2. ServerLocation was modified to include the memberID to differentiate
each server with the same hostname-for-sender and same pair of start and
end ports.
3. As ServerLocation is transmitted, there were a lot of changes in terms
of serialization etc. and also modification in ops code.

Suggestion:
- Instead, can we create a new class that contains the memberID and
ServerLocation and that new class object is added as a key in the
connectionMap.
- When member leaves, only that entry is removed from the connectionMap.
- When the remote locator is requesting the receiver information we
continue sending the ServerLocation, that we extract from the newly created
class.

Advantage:
- No changes required in terms of serialization as we are still sending the
ServerLocation like before.
- No changes to the ops.
- No extra bits sent over the wire


Please do let us know what do you feel about this solution.

Regards
Naba








On Tue, Jan 21, 2020 at 7:01 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> I have been implementing a possible solution for this issue, and although
> I have not finished yet, I would like to kindly ask for comments.
>
> I created some Helm charts to explain and reproduce the problem, if you
> are interested they are here:
> https://github.com/alb3rtobr/geode-cloudnative-wan-replication
>
> The solution consists on adding to ServerLocation the id of the member
> hosting the server, to allow to differentiate two or more gateway receivers
> with the same ip but that are in different locations. I verified that this
> change fixes the problem.
>
> After that, I have been working on fixing issues with the existing tests.
> In the meanwhile, it will be useful to get some feedback about the
> solution, specially if there are impacts I have not considered yet (maybe
> they are the reason for the failing tests Im currently working on).
>
> The code can be found on this PR:
> https://github.com/apache/geode/pull/4489
>
> Thanks in advance!
>
> Alberto B.
>
>
> 
> De: Anilkumar Gingade 
> Enviado: viernes, 6 de diciembre de 2019 18:56
> Para: geode 
> Cc: Charlie Black 
> Asunto: Re: WAN replication issue in cloud native environments
>
> Alberto,
>
> Can you please file a JIRA ticket for this. This could come up often as
> more and more deployments move to K8s.
>
> -Anil.
>
>
> On Fri, Dec 6, 2019 at 8:33 AM Sai Boorlagadda 
> wrote:
>
> > > if one gw receiver stops, the locator will publish to any remote
> locator
> > that there are no receivers up.
> >
> > I am not sure if locators proactively update remote locators about change
> > in receivers list rather I think the senders figures this out on
> connection
> > issues.
> > But I see the problem that local-site locators have only one member in
> the
> > list of receivers that they maintain as all receivers register with a
> > single  address.
> >
> > One idea I had earlier is to statically set receivers list to locators
> > (just like remote-locators property) which are exchanged with gw-senders.
> > This way we can introduce a boolean flag to turn off wan discovery and
> use
> > the statically configured addresses. This can be also useful for
> > remote-locators if they are behind a service.
> >
> > Sai
> >
> > On Thu, Dec 5, 2019 at 2:33 AM Alberto Bustamante Reyes
> >  wrote:
> >
> > > Thanks Charlie, but the issue is not about connectivity. Summarizing
> the
> > > issue, the problem is that if you have two or more gw receivers that
> are
> > > started with the same value of "hostname-for-senders", "start-port" and
> > > "end-port" (being "start-port" and "end-port" equal) parameters, if one
> > gw
> > > receiver stops, the locator will publish to any remote locator that
> there
> > > are no receivers up.
> > >
> > > And this use case is likely to happen on cloud-native environments, as
> > > described.
> > >
> > > BR/
> > >
> > > Alberto B.
> > > 
> > > De: Charlie Black 
> > > Enviado: miércoles, 4 de diciembre de 2019 18:11
> > > Para: dev@geode.apache.org 
> > > Asunto: Re: WAN replication issue in cloud native environments
> > >
> > > Alberto,
> > >
> > > Something else to think about SNI based routing.   I believe Mario
> might
> > be
> > > working on adding SNI to Geode - he at least had a proposal that he
> > > e-mailed out.
> > >
> > > Basics are the destination host is in the SNI field and the proxy can
> > > inspect and route the request to the right service instance. Plus
> we
> > > have the option to not terminate the SSL at the proxy.
> > >
> > > Full disclosure - I haven't tried out SNI based routing myself and it
> is
> > > something that I thought could

Re: [PROPOSAL]: Include GEODE-7728 in Release 1.12.0

[Nabarun Nag]

++

On Wed, Feb 5, 2020 at 9:54 AM Alexander Murmann 
wrote:

> +1
>
> On Wed, Feb 5, 2020 at 9:29 AM Udo Kohlmeyer  wrote:
>
> > +1 - for inclusion
> >
> > On 2/5/20 4:22 AM, Ju@N wrote:
> > > Hello devs,
> > >
> > > I'd like to include the fix for GEODE-7728 [1] in release 1.12.0.
> > > The change is basically to avoid throwing an exception and return the
> > > correct result whenever a query has more than one condition and one of
> > them
> > > compares two indexed fields.
> > > This is not a new issue but it can be hit by any user under the
> > conditions
> > > I've mentioned, it is also considered critical for one of the
> customers I
> > > work for, thus I'm eagerly asking to include the fix in the next
> release.
> > > The SHA is 6e35c201ea605075433203d4e64ca887bafd8fcb [2].
> > > Best regards.
> > >
> > > [1]: https://issues.apache.org/jira/browse/GEODE-7728
> > > [2]:
> > >
> >
> https://github.com/apache/geode/commit/6e35c201ea605075433203d4e64ca887bafd8fcb
> > >
> >
>

Re: [PROPOSAL]: Include GEODE-7789 in Release 1.12.0

[Nabarun Nag]

+1

On Thu, Feb 13, 2020 at 2:09 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to include the fix for GEODE-7789 [1] in release 1.12.0.
> The change prevents a performance degradation introduced in Geode 1.11, it
> basically shows up on clusters where there's at least one client with
> subscription enabled.
> The SHA is 71e156a55228d89efafd048e1533debba606c064 [2].
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7789
> [2]:
>
> https://github.com/apache/geode/commit/71e156a55228d89efafd048e1533debba606c064
>
> --
> Ju@N
>

[ANNOUNCE] geode-kafka-connector

[Nabarun Nag]

Hi Geode Community,

In the past 2 weeks, Jason Huynh coded up an Apache Kafka - Apache Geode
connector which is able to use Apache Geode as a sink and as a source.

We are very pleased to announce that the code is now open-sourced under
Apache Software Foundation repositories and is available at
https://github.com/apache/geode-kafka-connector

We have tested basic features including security and are experimenting with
integration with cloud platforms. Currently, Donal Evans and I along with
Jason are getting other features completed which are required by Confluent
to get the connector certified.

We will highly appreciate any feedback and contributions from the
community. Please do reach out to us if you have any questions or concerns.

We will reach out to the community when we are ready with the first release.

Regards
Nabarun Nag

[ANNOUNCE] OQL Method Invocation Security

[Nabarun Nag]

Hi Geode Community,

We are pleased to announce that the work on OQL Method Invocation Security
work has been completed and pushed to develop. It will be available in the
next release - Apache Geode 1.12

These following goals have been achieved:

   - Pluggable method authorizers.
   - OQL method invocation security "on" by default when Security is
   enabled at the cluster level.
   - Authorizers stored and retrieved through the cluster configuration
   service.
   - QueryService.allowUntrustedMethodInvocation marked as deprecated.
   - Prevents RCE (Remote Code Execution) exploits and other
   vulnerabilities in OQL expressions when security is enabled at the cluster
   level.
   - Configurable in runtime
   - Invoke methods on domain classes (present on the system classpath or
   deployed through gfsh) as part of OQL queries, relatively easy and with
   little to no configuration changes.


These following method authorizers are available out of the box:

   - RestrictedMethodAuthorizer
   - UnrestrictedMethodAuthorizer
   - RegExMethodAuthorizer
   - JavaBeanAccessorMethodAuthorizer


Details about architecture can be found here:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security


Regards
Nabarun Nag

OQL Method Authorizer Blog

[Nabarun Nag]

Hi Geode Community,

Please do visit the blog that Juan Ramos has put up on the OQL Method
Authorizer :
https://jujoramos.blogspot.com/2020/02/pluggable-oql-method-authorization.html

Thank you Juan for this effort.

Regards
Nabarun Nag

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

[Nabarun Nag]

What help is needed in this effort?

Regards
Naba

On Fri, Feb 28, 2020 at 11:35 AM Mark Hanson  wrote:

> Alright, so basically it seems like people are not ok with the not
> requiring stressnewtest approach. So I guess that means that we need to
> identify -1s willing to help resolve this problem…
>
> Who would like to help?
>
> Thanks,
> Mark
>
> > On Feb 28, 2020, at 11:12 AM, Ernest Burghardt 
> wrote:
> >
> > -1 to limiting any tests... if there are issues with the tests let's fix
> > that.  we have too many commits coming in with little or no testing over
> > new/changed code, so I can't see how removing any existing test coverage
> as
> > a good idea
> >
> > Best,
> > EB
> >
> > On Fri, Feb 28, 2020 at 10:58 AM Mark Hanson  wrote:
> >
> >> Just to make sure we are clear, I am not suggesting that we disable
> >> stressnewtest, but that we make it not required. It would still run and
> >> provide feedback, but it would not give us an unwarranted green in my
> >> approach.
> >>
> >>> On Feb 28, 2020, at 10:49 AM, Ju@N  wrote:
> >>>
> >>> +1 to what Owen said, I don't think disabling *StressNewTest* is a
> >>> good idea.
> >>>
> >>> On Fri, 28 Feb 2020 at 18:35, Owen Nichols 
> wrote:
> >>>
>  -1 to making StressNew not required
> 
>  +1 to eliminating the current loophole — StressNew should never give a
>  free pass.
> 
>  Any time your PR is having trouble passing StressNew, please bring it
> up
>  on the dev list. We can review on a case-by-case basis and decide
> >> whether
>  to try increasing the timeout, changing the repeat count, refactoring
> >> the
>  PR, or as an absolute last resort requesting authorization for an
> >> override
>  (for example, a change to spotless rules might touch a huge number of
> >> files
>  but carry no risk).
> 
>  One bug we should fix is that StressNew sometimes counts more files
>  touched than really were, especially if you had many commits or merges
> >> or
>  rebases on your PR branch.  Possible workarounds there include
> squashing
>  and/or creating a new PR and/or splitting into multiple PRs.  I’ve
> spent
>  some time trying to reproduce why files are mis-counted, with no
> >> success,
>  but perhaps someone cleverer with git could provide a fix.
> 
>  Another issue is that StressNew is only in the PR pipeline, not the
> main
>  develop pipeline.  This feels like an asymmetry where PRs must pass a
>  “higher” standard.  We should consider adding some form of StressNew
> to
> >> the
>  main pipeline as well (maybe compare to the previous SHA that
> passed?).
> 
>  The original motivation for the 25-file limit was an attempt to limit
> >> how
>  long StressNew might run for.  Since concourse already applies a
> >> timeout,
>  that check is unnecessary.  However, a compromise solution might be to
> >> use
>  the number of files changed to dial back the number of repeats, e.g.
> >> stay
>  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 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
>  polluting other tests in unexpected ways?  It might be useful to run a
>  “StressNew” with repeats=2 over a much broader scope, maybe even all
> >> tests,
>  at least once in a while?
> 
> 
> > On Feb 28, 2020, at 9:51 AM, Mark Hanson  wrote:
> >
> > 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, relating to run time being too long to
> be
>  tracked by concourse, so we just let it through as a pass. I think
> this
> >> is
>  a bad signal. I think that this should automatically be a failure in
> the
>  short term. As a result, I also think it should not be required. It
> is a
>  bad signal, and I think that by making it a fail, this will at least
> not
>  give us a false sense of security. I understand that this opens the
> >> flood
>  gates so to speak, but I don’t think as a community it is a big
> problem
>  because we can still say that you should not merge if the
> StressNewTest
>  fails because of your test.
> >
> > I personally find the false sense of security more troubling than
>  anything. Hence the reason, I would like this to be
> >
> > Let me know what you think..
> >
> > Thanks,
> > Mark
> 
> 
> >>>
> >>> -

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

[Nabarun Nag]

+1

On Fri, Mar 6, 2020 at 6:33 PM Donal Evans  wrote:

> With fairly apt timing, we've recently had a PR merged (
> https://github.com/apache/geode/pull/4745) that introduced a test that has
> resulted in fairly consistently flaky failures in the pipeline (JIRA
> ticket: https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7843).
> The PR was quite large and touched/created a lot of tests, so StressNewTest
> never ran on it:
> https://concourse.apachegeode-ci.info/builds/136784#L5e3ac3fc:2. Given how
> frequently the test is failing in the pipeline (11 failures on various
> IntegrationTest jobs over the past 6 commits), it seems very likely that
> had StressNewTest been allowed to run, this issue would have been caught at
> the PR stage and could have been remedied then, instead of resulting in a
> nearly constantly red pipeline.
>
> I've already given my +1 to this proposal, but this situation has prompted
> me to make it a *+1*.
>
> On Tue, Mar 3, 2020 at 2:08 PM Anilkumar Gingade 
> wrote:
>
> > The stress test is to identify the flaky-ness within the test; and
> assuming
> > any changes to the test may have introduced the flaky-ness.
> > It's about paying the cost upfront or later when the test is determined
> to
> > be flaky.
> > If 25+ tests have been changed in a PR, the cost of running stress test
> for
> > those;  and gating the PR for so long.
> > Knowing how much pain it causes to fix a flaky test after a certain/long
> > duration of time; I am +1 for doing this change.
> >
> > On Tue, Mar 3, 2020 at 10:06 AM Dan Smith  wrote:
> >
> > > What's the current timeout for StressNewTest? Maybe if we just up the
> > > threshold to 100 tests or so and up the timeout to match we can catch
> > > pretty much all PRs.
> > >
> > > I'm not sure why the job is flagging more tests than it should. It
> looks
> > > like at some point @rhoughon changed it to read the merge base from
> some
> > > file created by concourse as an optimization [1] - I suspect maybe that
> > > file is inaccurate?
> > >
> > > I originally wrote this job. It's definitely not a panacea, it will
> only
> > > catch a new flaky test if
> > >  - the test is really flaky (likely to fail more than 1/50 times)
> > >  - the change actually happened in the test file itself, and not the
> > > product or some other test file.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/geode/commit/4c06ba4625e69d44a5165aa9f2fccddfc064de87
> > >
> > > -Dan
> > >
> > > On Sun, Mar 1, 2020 at 9:00 PM Owen Nichols 
> wrote:
> > >
> > > > We don’t tend to look too closely at successful PR checks to see
> > whether
> > > > they actually checked anything at all.
> > > >
> > > > One example I found is
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/5957
> > > > <
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/5957
> > > > >:
> > > > 32 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.
> > > >
> > > > Here are 92 more examples (url’s omitted for brevity — use the
> example
> > > > above as a template and just replace the last 4 digits):
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6243)
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6249)
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6402)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6262)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6430)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6439)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6449)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6454)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6458)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6459)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6224)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6441)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6448)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

[Nabarun Nag]

+1

On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh  wrote:

> Hello Dev list,
>
> I'd like to include a fix for GEODE-7763 in release 1.12.0.
> The change removes the call to exportValue, preventing a serialization,
> when no clients are waiting for the specific event.
> The reason why I think it should be in the release is that we noticed a
> negative effect on performance for a specific use case, in 1.12 from a
> change that made us more "consistent" in that use case.  This change
> doesn't modify the fix much, but does bring performance back inline (if not
> better) than before.
>
> The sha is b4c3e9413f0008635b0a0c9116c96147d1e4ceec
>
> Thanks,
> -Jason
>

[VOTE] Using Github issues and wiki for geode-kafka-connector project

[Nabarun Nag]

Hello team,

We are planning to experiment with using Github issues and wiki for the
Apache project *Geode-Kafka-Connector. *(not Apache Geode project). Please
do give your vote on this as we need to send the vote link to infra to
activate it.

*Why are we doing this ? / Advantages* :
1. *Unified location* to have documentation, code and issue tracking.
2. Leverage Github tools like Github pages to create websites hosting
information about the project.
3. No separate JIRA accounts or permission required to create issues.
4. This will have *no impact on the broader Geode community* as right now
only 3-4 developers involved in this project.
5. *This is an experiment.* If things do not work out we can always revert
back to the traditional way of having separate JIRA, documentation,
websites etc.

*Precedence*:
1. Kubernetes uses the github issues
2. RabbitMQ uses github issues.


*NOTE: *- Please be cordial and do not use any condescending language and
absolutely no bullying.
- Please treat this email as a professional business email and maintain
email etiquette while replying.

Regards
Nabarun

[ANNOUNCE] Github Wiki and Issus are now activated on geode-kafka-connector

[Nabarun Nag]

Hi,

Issues are wiki pages  are now active on the geode-kafka-connector
repository. Thank you all for the kind votes.

Regards
Nabarun Nag

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Nabarun Nag]

Hi Anthony!

Sorry for the late reply but I was doing some research. The issues and wiki
section as of now has been used by few engineers only and Confluent has not
yet entered any issues as they are still reviewing the project. I went
ahead and looked into all projects in the Apache domain using issues and
the extra features they enable.
*JIRA vs Issues:*

   - There are a sizable number of Apache projects who are using GitHub
   issues
   - One clear advantage is the automatic linking of PRs and Issues. Issues
   can be closed automatically once the PR is merged.
   - It can also enable a feature to delete the feature branch
   automatically once the PRs is merged (we have lot unused feature/GEODE-
   branches in origin which were not deleted after merging PRs)
   - It enables us to use Github Project management(Github version of
   PivotalTracker)  which is integrated with Github issues and PRs and all the
   movement from "To-do", "In-progress", "resolved" and "closed" are automated
   depending on if a PR is opened, requires reviews, reviewed and merged state.

*Github Wiki vs Confluence Wiki:*

   - As you have mentioned that visibility is more important, we can follow
   other open-source products like Greenplum, Hystrix and we can use the wiki
   page to explain stuff like how to contribute, basic architecture, internal
   knowledge, i.e information that is needed to contribute to Geode.
   - A signification advantage is the colocation of code and wiki. Any
   developer can find Geode GitHub repo and that person now has all the tools
   needed to start contributing.


A few examples of well-written wikis on GitHub:

   - https://github.com/d3/d3/wiki
   - https://github.com/Netflix/Hystrix/wiki
   - https://github.com/apache/helix/wiki


ASF: word on the street is that it was mentioned in ApacheCon, that they
support the use of Github wiki and issues in ASF projects, and this can
also be seen in multiple INFRA tickets mentioning enabling wiki.

I am also looking into ZenHub to improve our workflow. ZenHub is a very
robust project management tools used by Apache Contributors and
corporations like VMware.

Regards
Nabarun Nag


On Thu, Apr 23, 2020 at 2:40 PM Anthony Baker  wrote:

> Having used pretty every style of wiki, I care less about the wiki tech
> and more about making the content easily accessible and discoverable for
> our users and contributors.  Our current wiki has a lot of useful
> information.  I’d like to understand how we want to use repo-specific
> wiki’s to augment or replace our current project wiki (or neither)\ before
> taking any decisions.
>
> Anthony
>
>
> > On Apr 23, 2020, at 12:54 PM, Blake Bender  wrote:
> >
> > GitHub Wiki supports Markdown, our current one does not.  This means
> GitHub
> > wins by default in my book.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:
> >
> >> Naba, do you have any updates to share?  I’m curious if you have found
> >> this useful compared to JIRA.
> >>
> >> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
> >> does that compare with centralizing our information in the ASF
> confluence
> >> wiki?
> >>
> >> Thanks,
> >> Anthony
> >>
> >>
> >>> On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> >>>
> >>> Hello team,
> >>>
> >>> We are planning to experiment with using Github issues and wiki for the
> >>> Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> >> Please
> >>> do give your vote on this as we need to send the vote link to infra to
> >>> activate it.
> >>>
> >>> *Why are we doing this ? / Advantages* :
> >>> 1. *Unified location* to have documentation, code and issue tracking.
> >>> 2. Leverage Github tools like Github pages to create websites hosting
> >>> information about the project.
> >>> 3. No separate JIRA accounts or permission required to create issues.
> >>> 4. This will have *no impact on the broader Geode community* as right
> now
> >>> only 3-4 developers involved in this project.
> >>> 5. *This is an experiment.* If things do not work out we can always
> >> revert
> >>> back to the traditional way of having separate JIRA, documentation,
> >>> websites etc.
> >>>
> >>> *Precedence*:
> >>> 1. Kubernetes uses the github issues
> >>> 2. RabbitMQ uses github issues.
> >>>
> >>>
> >>> *NOTE: *- Please be cordial and do not use any condescending language
> and
> >>> absolutely no bullying.
> >>> - Please treat this email as a professional business email and maintain
> >>> email etiquette while replying.
> >>>
> >>> Regards
> >>> Nabarun
> >>
> >>
>
>

Re: GitHub Project Board Applications API

[Nabarun Nag]

It is just an experiment at the moment. We are researching ways of
automating processes. It is an exploration attempt hence not being
discussed at this point in time as we don't have all the information.

Regards
Naba


On Fri, May 1, 2020 at 4:00 PM Michael Oleske  wrote:

> Hi Devs!
>
> I saw on github that the main geode project now has a project board (
> https://github.com/apache/geode/projects/1).  I don't remember it being
> discussed on the dev list.  Are some folks using it now for organization?
> I'm curious how that flow works since our Jira could also be doing that
> flow.  I ask cause I'm definitely one of those folks who'd like to
> consolidate things closer to code (so github issues and the like).  I'm
> wondering who's it is helping since we as an open source community haven't
> really talked about making project boards/kanban boards all that often with
> the tools we do have.
>
> -michael
>

Re: GitHub Project Board Applications API

[Nabarun Nag]

We can ignore this board as it is not part of the agreed-upon open-source
process at the moment.
Regards
Naba

On Fri, May 1, 2020 at 4:26 PM Nabarun Nag  wrote:

> It is just an experiment at the moment. We are researching ways of
> automating processes. It is an exploration attempt hence not being
> discussed at this point in time as we don't have all the information.
>
> Regards
> Naba
>
>
> On Fri, May 1, 2020 at 4:00 PM Michael Oleske  wrote:
>
>> Hi Devs!
>>
>> I saw on github that the main geode project now has a project board (
>> https://github.com/apache/geode/projects/1).  I don't remember it being
>> discussed on the dev list.  Are some folks using it now for organization?
>> I'm curious how that flow works since our Jira could also be doing that
>> flow.  I ask cause I'm definitely one of those folks who'd like to
>> consolidate things closer to code (so github issues and the like).  I'm
>> wondering who's it is helping since we as an open source community haven't
>> really talked about making project boards/kanban boards all that often
>> with
>> the tools we do have.
>>
>> -michael
>>
>

Re: GitHub Project Board Applications API

[Nabarun Nag]

>
> What are you hoping to learn from the exploration?

- what features are available and how can we use them.

What hypothesis is the experiment trying to prove/disprove?
>
Hypothesis: "Github project boards can help in project management."

Hopefully we may be able to use them in the near future.

Regards
Naba


On Fri, May 1, 2020 at 4:28 PM Michael Oleske  wrote:

> What are you hoping to learn from the exploration?  What hypothesis is the
> experiment trying to prove/disprove?
>
> -michael
>
> On Fri, May 1, 2020 at 4:26 PM Nabarun Nag  wrote:
>
> > It is just an experiment at the moment. We are researching ways of
> > automating processes. It is an exploration attempt hence not being
> > discussed at this point in time as we don't have all the information.
> >
> > Regards
> > Naba
> >
> >
> > On Fri, May 1, 2020 at 4:00 PM Michael Oleske 
> wrote:
> >
> > > Hi Devs!
> > >
> > > I saw on github that the main geode project now has a project board (
> > > https://github.com/apache/geode/projects/1).  I don't remember it
> being
> > > discussed on the dev list.  Are some folks using it now for
> organization?
> > > I'm curious how that flow works since our Jira could also be doing that
> > > flow.  I ask cause I'm definitely one of those folks who'd like to
> > > consolidate things closer to code (so github issues and the like).  I'm
> > > wondering who's it is helping since we as an open source community
> > haven't
> > > really talked about making project boards/kanban boards all that often
> > with
> > > the tools we do have.
> > >
> > > -michael
> > >
> >
>

Re: Our May 2020 report to the board

[Nabarun Nag]

Thank you Dave for putting together the report !! Thank you all for putting 
together those amazing blogs and all the Apache Geode contributors.

Regards
Naba



Get Outlook for iOS

From: Karen Miller 
Sent: Monday, May 11, 2020 2:30:35 PM
To: dev@geode.apache.org 
Subject: Our May 2020 report to the board

Apache Geode developers, please thank Dave Barnes for putting together
the May 2020 board report that I filed today.  Here is the contents of the
report:

## Description:
The mission of Apache Geode is the creation and maintenance of software
related to a data management platform that provides real-time, consistent
access to data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease) 226 issues closed in
JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic disruption to our
community's work routines, we feel these figures, though lower than those of
the previous reporting period, reveal an engaged and productive development
community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31 This release included improvements
  to the management REST API, .NET and C++ native clients, client/server
  security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced upticks in
discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though down 16%
and 26%, respectively, from the previous quarter. Points of emphasis included
error recovery improvements, API extensions, and compatibility to accommodate
containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article entitled "Apache
Geode as a remote Gradle Build Cache"
(https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b) along with an
accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March entitled "Geode
Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3), and
another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused PdxTypes
from an Apache Geode Distributed System"
(https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34).

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

[Nabarun Nag]

+1

On Thu, May 14, 2020 at 8:54 AM Donal Evans  wrote:

> Thanks for the explanation, Robert. Also, I realised I never explicitly
> said it in my earlier post, but this is a +1 from me
>
> On Thu, May 14, 2020 at 8:05 AM Joris Melchior 
> wrote:
>
> > This seems like a good thing to have.
> >
> > +1
> > 
> > From: Robert Houghton 
> > Sent: May 13, 2020 17:32
> > To: dev@geode.apache.org ; Mario Ivanac
> > 
> > Subject: [DISCUSS] enable GitHub PR blocking on API breaking changes
> >
> > We have enabled this job on the develop and support 1.13 branches, and it
> > is going well. I would like this to be a blocking job for our pull
> > requests.
> >
> > Are there any issues around this test that we want to address, or reasons
> > to *not* have it be a blocking job in the PR pipeline?
> >
> > To seed the conversation, there is an issue I am working on with @Mario
> > Ivanac  regarding exemptions to the Gradle task.
> >
> > I would like to have a [VOTE] by end of week on this.
> >
>

New blog on Spring Security & Geode by Juan Ramos

[Nabarun Nag]

Hi Geode Community,

Juan Ramos has recently published a new article on Spring Security and Apache 
Geode. You can read it here at 
https://medium.com/@jujoramos/spring-security-geode-4670faff47a0


Thank you Juan for this article.

Regards
Nabarun Nag

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

[Nabarun Nag]

- We are maintaining feature/GEODE-7665 which is the feature branch for PR 
clear work on which multiple developers are working on. 
- We are maintaining this in Geode repository.
- All sub-tasks of GEODE-7665 are merged into this feature branch.
- Anyone in the Geode community can work on any subtask 
- This is a long running, and a massive feature development which is 
manipulating core code on Apache Geode. Hence all work is pushed to the feature 
branch to keep develop isolated from a regression introduced in PR clear work.
- We have previously used release flags for Lucene work which we found to be 
inefficient and unnecessary extra work.

We vote that PR clear feature branch be maintained in the Geode Repository as 
this is a long running, massive effort involving everyone from the community.

When the PR clear tasks are completed, the branch will be rigorously tested and 
then squash merged into develop and the feature branch will be deleted.


Regards
Naba

-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 3:43 PM
To: dev@geode.apache.org
Subject: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

I know this has been brought up multiple times without resolution. I want us 
resolve to ban the use of Geode repository for work in progress, feature 
branches, or any other branches that are not release or support branches. There 
is no reason given the nature of GitHub why you can’t fork the repository to 
contribute.  

* Work done on these branches results in the ASF bots updating the associated 
JIRAs and email blasting all of us with your work. 

* People don’t clean up these branches, which leads to a mess of branches on 
everyones clones and in the UI.

* All your intermediate commits get synced to the repo, which bloats the repo 
for everyone else. Even your commits you rebase over and force push are left in 
the repo. When you delete your branch these commits are not removed. There is 
no way for us to prune unreferenced commits. Nobody else needs your commits 
outside of what was merged to a production branch.

If anyone has a use case for working directly from Geode repo that can’t work 
from a fork please post it here so we can resolve. 

Thanks,
Jake

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

[Nabarun Nag]

I don’t think it is right to make the open source Geode Community to work on my 
personal fork 

Regards
Naba


-Original Message-
From: Mark Hanson  
Sent: Tuesday, June 2, 2020 4:35 PM
To: dev@geode.apache.org
Subject: 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 have specified are possible within the confines of a fork.

Thanks,
Mark

On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:

- We are maintaining feature/GEODE-7665 which is the feature branch for PR 
clear work on which multiple developers are working on. 
- We are maintaining this in Geode repository.
- All sub-tasks of GEODE-7665 are merged into this feature branch.
- Anyone in the Geode community can work on any subtask 
- This is a long running, and a massive feature development which is 
manipulating core code on Apache Geode. Hence all work is pushed to the feature 
branch to keep develop isolated from a regression introduced in PR clear work.
- We have previously used release flags for Lucene work which we found to 
be inefficient and unnecessary extra work.

We vote that PR clear feature branch be maintained in the Geode Repository 
as this is a long running, massive effort involving everyone from the community.

When the PR clear tasks are completed, the branch will be rigorously tested 
and then squash merged into develop and the feature branch will be deleted.


Regards
Naba

-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 3:43 PM
To: dev@geode.apache.org
Subject: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

I know this has been brought up multiple times without resolution. I want 
us resolve to ban the use of Geode repository for work in progress, feature 
branches, or any other branches that are not release or support branches. There 
is no reason given the nature of GitHub why you can’t fork the repository to 
contribute.  

* Work done on these branches results in the ASF bots updating the 
associated JIRAs and email blasting all of us with your work. 

* People don’t clean up these branches, which leads to a mess of branches 
on everyones clones and in the UI.

* All your intermediate commits get synced to the repo, which bloats the 
repo for everyone else. Even your commits you rebase over and force push are 
left in the repo. When you delete your branch these commits are not removed. 
There is no way for us to prune unreferenced commits. Nobody else needs your 
commits outside of what was merged to a production branch.

If anyone has a use case for working directly from Geode repo that can’t 
work from a fork please post it here so we can resolve. 

Thanks,
Jake

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

[Nabarun Nag]

- Unified location, where anyone who wants to work on the feature can find the 
feature branch on the geode-repository 
- Visibility, the PRs to the geode repository can be viewed by everyone in the 
Geode community. Which will not happen if they are raised to my fork.
- Long running feature development happens in feature branches in Apache 
projects Eg: Lucene and Kafka.


Regards
Naba


-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 4:45 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches



> On Jun 2, 2020, at 4:40 PM, Nabarun Nag  wrote:
> 
> I don’t think it is right to make the open source Geode Community to work on 
> my personal fork 

Why not? I can fork your fork. I can PR to your fork. Its sort of what Git was 
made for, no single source repository.

Can you elaborate on why you feel it isn’t right?

-Jake

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

[Nabarun Nag]

I agree, I am not justifying the use of repository for small bug fixes etc. or 
short term individual tasks

I am justifying why PR clear  has a feature branch in the geode repository.

Regards
Naba


-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 4:48 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches



> On Jun 2, 2020, at 4:29 PM, Nabarun Nag  wrote:
> 
> - We are maintaining feature/GEODE-7665 which is the feature branch for PR 
> clear work on which multiple developers are working on. 
> - We are maintaining this in Geode repository.
> - All sub-tasks of GEODE-7665 are merged into this feature branch.
> - Anyone in the Geode community can work on any subtask 
> - This is a long running, and a massive feature development which is 
> manipulating core code on Apache Geode. Hence all work is pushed to the 
> feature branch to keep develop isolated from a regression introduced in PR 
> clear work.
> - We have previously used release flags for Lucene work which we found to be 
> inefficient and unnecessary extra work.
> 
> We vote that PR clear feature branch be maintained in the Geode Repository as 
> this is a long running, massive effort involving everyone from the community.
> 
> When the PR clear tasks are completed, the branch will be rigorously tested 
> and then squash merged into develop and the feature branch will be deleted.

I think there can always be exceptions for any rule. I can even understand the 
desire to have long running branches for large scale refactors or features 
maintained centrally. The issue is the most of the branches are not of this 
exceptional scale. I want to eliminate this clutter and consider exceptions 
where it makes sense. Perhaps which we could ask the ASF to have its bots 
ignore specifically prefixed branches to future reduce the noise produced by 
using the Geode repo in these exceptional cases.

-Jake

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

[Nabarun Nag]

Thank you Aaron.

We will continue using feature branch in ASF repo for development of PR clear 
work.

Yes, we can manage access to personal/non-ASF hosted forks but I do not have 
the list of people to set that up. This is automatic default when we create in 
ASF repositories.

Also, I am vehemently against using one person's personal fork for massive 
collaborative open source feature development involving the entire Geode 
Community. Every collaborator should have the same rights on the source code 
rather than a gatekeeper.

But again, I agree it is wrong to use the repo to create short living branches 
with single contributor and then not cleaning up after the branch is merged.

Regards
Naba

-Original Message-
From: Aaron Lindsey  
Sent: Wednesday, June 3, 2020 8:50 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

I'm on board with using forks — the exception being Naba's use case for long 
running feature branches where developers actually want to open a PR into the 
branch


From: Bruce Schuchardt 
Sent: Wednesday, June 3, 2020 8:23 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

Jake, you make some good points that I hadn't considered before.

On 6/2/20, 3:42 PM, "Jacob Barrett"  wrote:

I know this has been brought up multiple times without resolution. I want 
us resolve to ban the use of Geode repository for work in progress, feature 
branches, or any other branches that are not release or support branches. There 
is no reason given the nature of GitHub why you can’t fork the repository to 
contribute.

* Work done on these branches results in the ASF bots updating the 
associated JIRAs and email blasting all of us with your work.

* People don’t clean up these branches, which leads to a mess of branches 
on everyones clones and in the UI.

* All your intermediate commits get synced to the repo, which bloats the 
repo for everyone else. Even your commits you rebase over and force push are 
left in the repo. When you delete your branch these commits are not removed. 
There is no way for us to prune unreferenced commits. Nobody else needs your 
commits outside of what was merged to a production branch.

If anyone has a use case for working directly from Geode repo that can’t 
work from a fork please post it here so we can resolve.

Thanks,
Jake

Re: About Geode rolling downgrade

[Nabarun Nag]

Hi Mario and Alberto,

I will sync up with couple of engineers get you a feedback within a couple of 
days.

@Barry , Jason and I were discussing once, can your idea of WAN GII achieve the 
downgrade. Like create a DS with old versions and let it do a GII from the 
newer version cluster and then shutdown the new version DS. Now we have a DS 
with lower version.


Regards
Naba


From: Mario Ivanac 
Sent: Friday, June 5, 2020 1:19:42 AM
To: geode 
Subject: Odg: About Geode rolling downgrade

Hi all,

just a reminder that Alberto is still waiting for feedback,
regarding his question.

BR,
Mario

Šalje: Alberto Gomez 
Poslano: 14. svibnja 2020. 14:45
Prima: geode 
Predmet: Re: About Geode rolling downgrade

Hi,

I friendly reminder to the community about this request for feedback.

Thanks,

-Alberto G.

From: Alberto Gomez 
Sent: Thursday, May 7, 2020 10:44 AM
To: geode 
Subject: Re: About Geode rolling downgrade

Hi again,


Considering Geode does not support online rollback for the time being and since 
we have the need to rollback even a standalone system, we were thinking on a 
procedure to downgrade Geode cluster tolerating downtime, but without a need to:

  *   spin another cluster to sync from,
  *   do a restore or
  *   import data snapshot.



The procedure we came up with is:

  1.  First step - downgrade locators:

 *   While still on the newer version, export cluster configuration.
 *   Shutdown all locators. Existing clients will continue using their 
server connections. New clients/connections are not possible.
 *   Start new locators using the old SW version and import cluster 
configuration. They will form a new cluster. Existing client connections should 
still work, but new client connections are not yet possible (no servers 
connected to locators).

  1.  Second step – downgrade servers:

 *   First shutdown all servers in parallel. This marks the beginning of 
total downtime.
 *   Now start all servers in parallel but still on the new software 
version. Servers connect to the cluster formed by the downgraded locators. When 
servers are up, downtime ends. New client connections are possible. The rest of 
the rollback should be fully online.
 *   Now per server:

   i.  Shutdown 
it, revoke its disk-stores and delete its file system.

 ii.  Start 
server using old SW version. When up, server will take over cluster 
configuration and pick up replicated data and partitioned regions buckets 
satisfying region redundancy (essentially will hold exactly the same data 
previous server had).



The above has some important prerequisites:

  1.  Partitioned regions have redundancy and region configuration allows 
recovery as described above.
  2.  Clients version allows connection to new and old clusters - i.e. clients 
must not use newer version at the moment the procedure starts.
  3.  Geode guarantees cluster configuration exported from newer system can be 
imported into older system. In case of incompatibility I expect we could even 
manually edit the configuration to adapt it to the older system but it is a 
question how new servers will react when they connect (in step 2b).
  4.  Geode guarantees communication between peers with different SW version 
works and recovery of region data works.



Could we have opinions on this offline procedure? It seems to work well but 
probably has caveats we do not see at the moment.



What about prerequisites 3 and 4? It is valid in upgrade case but not sure if 
it holds in this rollback case.


Best regards,


-Alberto G.


From: Anilkumar Gingade 
Sent: Thursday, April 23, 2020 12:59 AM
To: geode 
Subject: Re: About Geode rolling downgrade

That's right, most/always no down-time requirement is managed by having
replicated cluster setups (Disaster-recovery/backup site). The data is
either pushed to both systems through the data ingesters or by using WAN
setup.
The clusters are upgraded one at a time. If there is a failure during
upgrade or needs to be rolled back; one system will be always up
and running.

-Anil.





On Wed, Apr 22, 2020 at 1:51 PM Anthony Baker  wrote:

> Anil, let me see if I understand your perspective by stating it this way:
>
> If cases where 100% uptime is a requirement, users are almost always
> running a disaster recovery site.  It could be active/active or
> active/standby but there are already at least 2 clusters with current
> copies of the data.  If an upgrade goes badly, the clusters can be
> downgraded one at a time without loss of availability.  This is because we
> ensure compatibility across the wan protocol.
>
> Is that correct?
>
>
> Anthony
>
>
>
> > On Apr 22, 2020, at 10:43 AM, Anilkumar Gingade 
> wrote:
> >
> >>> Rolling downgrade is a pre

RE: Setting your commit email address

[Nabarun Nag]

Hi Kirk, 

I think it is also now in the privacy setting in GitHub for anyone who wants to 
keep emails private. [https://github.com/settings/emails : 
https://github.com/settings/emails ]

This setting is needed for web based git operations like squash merging PRs etc.

In GitHub:
"Keep my email addresses private
We’ll remove your public profile email and use 
nabarun...@users.noreply.github.com when performing web-based Git operations 
(e.g. edits and merges) and sending email on your behalf. If you want command 
line Git operations to use your private email you must set your email in Git."

Regards
Nabarun

-Original Message-
From: Kirk Lund  
Sent: Wednesday, June 17, 2020 1:12 PM
To: dev@geode.apache.org
Subject: Setting your commit email address

Please make sure you've setup your commit email address. It makes it much 
easier to find out who committed something and how to contact them if there's a 
problem.

You typically use the following to set your email address globally in git:

$ git config --global user.email "em...@example.com"

You can also setup different repos with different email addresses by using:

$ git config user.email "em...@example.com"

In the below example, it's much easier to follow up with the author of the 1st 
commit than the author of the 2nd commit:

commit b1107d2e403404337c22830a4964eefc2490ef50
Author: John Doe 
Date:   Tue Jun 16 12:25:30 2020 -0700

GEODE-: add something new

commit e159238175766b46cbb6fe1e3459aa2da68db756
Author: John Doe 
Date:   Tue Jun 16 10:55:16 2020 -0700

GEODE-: fix something bad

For more info, see:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fsetting-up-and-managing-your-github-user-account%2Fsetting-your-commit-email-address&data=02%7C01%7Cnnag%40vmware.com%7C52882c4b78a34fd2ddfe08d812faa8f2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280215074685835&sdata=898w3f4jbFyTyQl8GAy1cFboW28VHCZAbl5ycwO8vX8%3D&reserved=0

Thanks,
Kirk

[VOTE] Backporting of GEODE-8261 to 1.13 release branch.

[Nabarun Nag]

Hi Geode devs,

Requesting vote to backport of GEODE-8261 to 1.13

Why?
This commit fixes an issue with servers throwing null pointer exceptions while 
a member is being shutdown and registering interest is in process.

SHA
720a4caea2ddb22296aa3225fc5264d2096cdf20


Regards
Nabarun

RE: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

[Nabarun Nag]

Thank you all for the  votes needed for the backport. It has been backported to 
support/1.13 branch

GEODE-8261: Added a null check for the proxyID. (#5251)

Regards
Naba


-Original Message-
From: Jianxia Chen  
Sent: Friday, June 19, 2020 12:22 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

+1

On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag  wrote:

> Hi Geode devs,
>
> Requesting vote to backport of GEODE-8261 to 1.13
>
> Why?
> This commit fixes an issue with servers throwing null pointer 
> exceptions while a member is being shutdown and registering interest is in 
> process.
>
> SHA
> 720a4caea2ddb22296aa3225fc5264d2096cdf20
>
>
> Regards
> Nabarun
>

Re: [PROPOSAL] backport GEODE-8394 to support/1.13

[Nabarun Nag]

Super +1

From: Anilkumar Gingade 
Sent: Friday, August 7, 2020 10:34 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL] backport GEODE-8394 to support/1.13

This causes a large object to be partially (corrupt data) stored in cache 
instead of throwing an exception.

Re: Draft of August 2020 Geode report to the board

[Nabarun Nag]

Hi Udo,

I think the wrapped links appear only in outlook. In Apache archives, they 
appear to be medium links.
Safelinks is feature enabled by default  in Outlook

Regards
Naba

Get Outlook for iOS

From: Udo Kohlmeyer 
Sent: Sunday, August 9, 2020 7:18:08 PM
To: dev@geode.apache.org 
Subject: Re: Draft of August 2020 Geode report to the board

Hi there Karen,

Any chance that you could pls change the URL to the proper Medium URLs and not 
the wrapped URLs?

—Udo
On Aug 7, 2020, 5:04 PM -0700, Karen Miller , wrote:
Thanks, Anthony. Here is Draft 2 of the August board report. Corrections
and comments by Monday at noon please.

## Description:
The mission of Apache Geode is the creation and maintenance of software
related
to a data management platform that provides real-time, consistent access to
data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
There are no issues requiring board attention.
- 309 issues opened in JIRA, past quarter (-3% decrease)
- 244 issues closed in JIRA, past quarter (1% increase)

## Membership Data:
Apache Geode was founded 2016-11-15 (4 years ago)
There are currently 109 committers and 54 PMC members in this project.

Community changes, past quarter:
- No new PMC members. Last addition was Alexander Murmann on 2020-03-26.
- No new committers. Last addition was Mario Kevo on 2020-03-23.

## Project Activity:
We're actively working on the version 1.13 release, with many discussions
over
code inclusions that delay the release, but provide a higher quality
product.

There is significant discussion and activity surrounding:
- WAN Configuration for an Ingress Proxy
- Avoiding the queuing of dropped events by the primary gateway sender when
the gateway sender is stopped
- Geode Redis API improvements
- Modularization / classloader isolation
- Support for an operation that clears a partitioned region

## Community Health:
The Apache Geode dev mailing list had a 26% decrease in traffic, while the
issues mailing list experienced a 32% increase in traffic in Q2.

We are planning a Geode content track for ApacheCon @Home. We have two days
of content based on submissions from the community.

May-July brought 7 new blog posts:
- "Spring Security & Geode" by community member Juan José Ramos at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40jujoramos%2Fspring-security-geode-4670faff47a0&data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826&sdata=xIzBXV2AMyAnWyMlIVWvQa3FWHB49fS9X8HZZxqH8wo%3D&reserved=0
- "Logging Apache Geode GatewaySender Queue Events" by community member
Barry
Oglesby at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F&data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826&sdata=GL6K7aaErRc5oInNPxBwjbS%2FvVUEDRliwgQX4zhxKww%3D&reserved=0

@boglesby_2508/logging-apache-geode-gatewaysender-queue-events-e7e19937a542
- "Verifying Apache Geode Region Consistency in Different Distributed
Systems"
by community member Barry Oglesby at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40boglesby_2508%2Fverifying-ap&data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826&sdata=%2BMGjWjRcNtZzzVkeRQjQy2KCl%2BQ9I2fG49Lp5eH4reg%3D&reserved=0

ache-geode-region-consistency-in-different-distributed-systems-e15d6edfe15d
- "Geode Write-Behind Event Handling with Spring JPA" by community member
Juan
José Ramos at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.co%2F&data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826&sdata=nfK%2FXnRiB0J2jmfzvQdlWvKIia%2FHVak2Rt30fYblNjM%3D&reserved=0

m/@jujoramos/geode-write-behind-event-handling-with-spring-jpa-a54f17e19709
- "Calculating the Size of an Apache Geode Region" by community member Barry
Oglesby at https://

medium.com/swlh/calculating-the-size-of-an-apache-geode-region-5ffb3b141464
- "Improving the Performance of Apache Geode Persistence Recovery" by
community member Jianxia Chen at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40luckycjx&data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826&sdata=XWMxVfmFpBsB9nwo6d7iQYk8Ody1ytsUK57uuNdD9fY%3D&reserved=0

/improving-the-performance-of-apache-geode-persistence-recovery-af08918d2ef
- "Threads Used in Apache Geode Function Execution" by community member
Barry
Oglesby at https://m

edium.com/swlh/threads-used-in-apache-geode-function-execution-9dd707cf227c