LGTM Project Name Change

[Jacob Barrett]

All,

The LGTM project name for Geode has changed to match our GitHub name, dropping 
the old incubator prefix. You can now find it at 
https://lgtm.com/projects/g/apache/geode. 

-Jake

Re: Geode Native & Apache Geode 1.8 Release

[Anthony Baker]

I think the source headers and LICENSE are in good shape.  I was able to follow 
BUILDING.md on macOS.  At some point it would be nice to provide a simple a 
quick start guide (e.g. How to create a geode-native app in 5 simple steps).  
Perhaps that is already included in the docs though.

Anthony


> On Nov 5, 2018, at 10:06 AM, Ernest Burghardt  wrote:
> 
> geode-native should be ready to go now
> 
> On Tue, Oct 30, 2018 at 2:56 PM Dave Barnes  wrote:
> 
>> unix_index.html and win_index.html cannot simply be removed, as they're
>> referenced by Cmake. I created a ticket to address this:
>> https://issues.apache.org/jira/browse/GEODE-5958.
>> 
>> On Tue, Oct 30, 2018 at 11:48 AM Dave Barnes  wrote:
>> 
>>> Re: the docs links mentioned in Anthony's message:
>>> 
>>> docs/README.md - the reference to the Geode CONTRIBUTE.md file is useful.
>>> I think we can assume that a user of the geode-native API will have a
>> Geode
>>> installation, too.
>>> docs/api/unix_index.html and docs/api/win_index.html - These files (and
>>> their bad links) are no longer needed and can be removed.
>>> 
>>> On Tue, Oct 30, 2018 at 7:48 AM Anthony Baker  wrote:
>>> 
 I ran rat manually and got this:
 
 Files with unapproved licenses:
 
  /geode/.cpackignore
  /geode/.lcovrc
  /geode/clicache/src/native_shared_ptr.hpp
  /geode/templates/security/CMakeLists.txt.forInstall
 
 Shouldn’t these failures be causing travis to fail?
 
 Many of the files rat that marks as binary have this the annoying BOM
>> [1]
 from visual studio.  Seems like we should just remove those.  That will
 reveal a number of files that need a license header.
 
 What is this file?  Seems to be binary content:
clicache/test/native_shared_ptrTests.cpp
 
 I also noticed this text that should be updated to point to where we
 intend to host the documentation (on the geode website):
 
 docs/README.md:The Geode-Native repository provides the full source for
 the Apache Geode Native Client User Guide in markdown format (see
 _geode-project-dir_/geode-docs/CONTRIBUTE.md for more information on
>> how to
 use markdown in this context). Users can build the markdown into an HTML
 user guide using [Bookbinder](https://github.com/pivotal-cf/bookbinder)
 and the instructions below.
 docs/api/unix_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
 target="_blank">Pivotal GemFire Native Client Documentation.
 docs/api/win_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
 target="_blank">Pivotal GemFire Native Client Documentation.
 
 
 Anthony
 
 [1] https://en.wikipedia.org/wiki/Byte_order_mark
 
> On Oct 29, 2018, at 12:11 PM, Jacob Barrett 
 wrote:
> 
> There are a lot of files that rat is seeing as binary files and
>> ignoring
> the headers. Many of those files are not binary. Perhaps they have the
> wrong metadata associated with them in git as a result of bad commits.
 We
> should clean all those files up so that rat is checking everything
> correctly.
> 
> On Thu, Oct 18, 2018 at 3:41 PM Dan Smith  wrote:
> 
>> Following up on this - is there anything we still need to do before
>> we
 cut
>> the 1.8 release branch in 2 weeks?
>> 
>> Overall I think the native client source code looks like it's in good
 shape
>> - we're running rat, the LICENSE and NOTICE look good, no binaries in
 the
>> source, etc.
>> 
>> For cutting the release branch, do we have criteria other than
>> passing
>> travis [1] ?
>> What will our release steps should look like for the native client -
 just
>> tar up the source and sign it with gpg?
>> 
>> If we can have this figured out ahead of time and at least
 provisionally
>> added to the release steps [2] I think it will help this release go a
>> little smoother.
>> 
>> [1] https://travis-ci.org/apache/geode-native/branches
>> [2]
>> 
 
>> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
>> 
>> On Thu, Oct 11, 2018 at 3:23 PM Dan Smith  wrote:
>> 
>>> +1 for a source release. Awesome!
>>> 
>>> -Dan
>>> 
>>> On Thu, Oct 11, 2018 at 2:32 PM Michael Oleske 
>> wrote:
>>> 
 Plus 1 for source release. Exciting times we live in!
 
 For verifying, plus one to a pipeline that's not just travis.
>> Though
 they're instructions in the repo about how to run tests to get that
 baseline confidence.
 
 -michael
 
 On Wednesday, October 10, 2018, Anilkumar Gingade <
 aging...@pivotal.io>
 wrote:
 
> Good work team.
> +1 to get this as part of Geode 1.8 release.
> It will be good to see community taking advantage 

Re: Geode Native & Apache Geode 1.8 Release

[Jacob Barrett]

There are examples that should cover this.

> On Nov 7, 2018, at 8:47 AM, Anthony Baker  wrote:
> 
> I think the source headers and LICENSE are in good shape.  I was able to 
> follow BUILDING.md on macOS.  At some point it would be nice to provide a 
> simple a quick start guide (e.g. How to create a geode-native app in 5 simple 
> steps).  Perhaps that is already included in the docs though.
> 
> Anthony
> 
> 
>> On Nov 5, 2018, at 10:06 AM, Ernest Burghardt  wrote:
>> 
>> geode-native should be ready to go now
>> 
>>> On Tue, Oct 30, 2018 at 2:56 PM Dave Barnes  wrote:
>>> 
>>> unix_index.html and win_index.html cannot simply be removed, as they're
>>> referenced by Cmake. I created a ticket to address this:
>>> https://issues.apache.org/jira/browse/GEODE-5958.
>>> 
 On Tue, Oct 30, 2018 at 11:48 AM Dave Barnes  wrote:
 
 Re: the docs links mentioned in Anthony's message:
 
 docs/README.md - the reference to the Geode CONTRIBUTE.md file is useful.
 I think we can assume that a user of the geode-native API will have a
>>> Geode
 installation, too.
 docs/api/unix_index.html and docs/api/win_index.html - These files (and
 their bad links) are no longer needed and can be removed.
 
> On Tue, Oct 30, 2018 at 7:48 AM Anthony Baker  wrote:
> 
> I ran rat manually and got this:
> 
> Files with unapproved licenses:
> 
> /geode/.cpackignore
> /geode/.lcovrc
> /geode/clicache/src/native_shared_ptr.hpp
> /geode/templates/security/CMakeLists.txt.forInstall
> 
> Shouldn’t these failures be causing travis to fail?
> 
> Many of the files rat that marks as binary have this the annoying BOM
>>> [1]
> from visual studio.  Seems like we should just remove those.  That will
> reveal a number of files that need a license header.
> 
> What is this file?  Seems to be binary content:
>   clicache/test/native_shared_ptrTests.cpp
> 
> I also noticed this text that should be updated to point to where we
> intend to host the documentation (on the geode website):
> 
> docs/README.md:The Geode-Native repository provides the full source for
> the Apache Geode Native Client User Guide in markdown format (see
> _geode-project-dir_/geode-docs/CONTRIBUTE.md for more information on
>>> how to
> use markdown in this context). Users can build the markdown into an HTML
> user guide using [Bookbinder](https://github.com/pivotal-cf/bookbinder)
> and the instructions below.
> docs/api/unix_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
> target="_blank">Pivotal GemFire Native Client Documentation.
> docs/api/win_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
> target="_blank">Pivotal GemFire Native Client Documentation.
> 
> 
> Anthony
> 
> [1] https://en.wikipedia.org/wiki/Byte_order_mark
> 
>> On Oct 29, 2018, at 12:11 PM, Jacob Barrett 
> wrote:
>> 
>> There are a lot of files that rat is seeing as binary files and
>>> ignoring
>> the headers. Many of those files are not binary. Perhaps they have the
>> wrong metadata associated with them in git as a result of bad commits.
> We
>> should clean all those files up so that rat is checking everything
>> correctly.
>> 
>>> On Thu, Oct 18, 2018 at 3:41 PM Dan Smith  wrote:
>>> 
>>> Following up on this - is there anything we still need to do before
>>> we
> cut
>>> the 1.8 release branch in 2 weeks?
>>> 
>>> Overall I think the native client source code looks like it's in good
> shape
>>> - we're running rat, the LICENSE and NOTICE look good, no binaries in
> the
>>> source, etc.
>>> 
>>> For cutting the release branch, do we have criteria other than
>>> passing
>>> travis [1] ?
>>> What will our release steps should look like for the native client -
> just
>>> tar up the source and sign it with gpg?
>>> 
>>> If we can have this figured out ahead of time and at least
> provisionally
>>> added to the release steps [2] I think it will help this release go a
>>> little smoother.
>>> 
>>> [1] https://travis-ci.org/apache/geode-native/branches
>>> [2]
>>> 
> 
>>> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
>>> 
 On Thu, Oct 11, 2018 at 3:23 PM Dan Smith  wrote:
 
 +1 for a source release. Awesome!
 
 -Dan
 
 On Thu, Oct 11, 2018 at 2:32 PM Michael Oleske 
>>> wrote:
 
> Plus 1 for source release. Exciting times we live in!
> 
> For verifying, plus one to a pipeline that's not just travis.
>>> Though
> they're instructions in the repo about how to run tests to get that
> baseline confidence.
> 
> -michael
> 
> On

Re: Questions about Poms and Publishing

[Jacob Barrett]

The dependency management element applies dependency constraints to first class 
dependencies and transitive dependencies. For example in dependency management 
of this say A:1 and B:2 it does not mean your module will necessarily depend on 
A:1 and B:2 but if the module or transitive module does that the versions will 
be nudged to match these constraints. So then if you module you have a 
dependency section that includes A it will become A:1 and if A:1 depends on B:1 
then B:1 will be nudged to B:2.

-Jake


> On Nov 6, 2018, at 3:25 PM, Anthony Baker  wrote:
> 
> I want reproducible builds.  If dependency locking [1] works I would be open 
> to dynamic versions [2].
> 
> Anthony
> 
> [1] https://docs.gradle.org/current/userguide/dependency_locking.html
> [2] 
> https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:declaring_dependency_with_dynamic_version
> 
> 
> 
>> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg  wrote:
>> 
>> My current question surrounds the structure of POMs in specifying version
>> information.  Gradle supports `dependency constraints` to unify library
>> versioning.  This seems to me to be a clean, concise alternative to our
>> current approach of cluttering the project property space with
>> project.'library.version', with mixed adherence throughout our build files.
> 

Re: Geode Native & Apache Geode 1.8 Release

[Anthony Baker]

Yes, I found the examples, but having a top-level guided HelloWorld walk 
through would be helpful.  I’ll hold this thought until we publish the docs and 
see what’s there.

Thanks,
Anthony


> On Nov 7, 2018, at 9:01 AM, Jacob Barrett  wrote:
> 
> There are examples that should cover this.
> 
>> On Nov 7, 2018, at 8:47 AM, Anthony Baker  wrote:
>> 
>> I think the source headers and LICENSE are in good shape.  I was able to 
>> follow BUILDING.md on macOS.  At some point it would be nice to provide a 
>> simple a quick start guide (e.g. How to create a geode-native app in 5 
>> simple steps).  Perhaps that is already included in the docs though.
>> 
>> Anthony
>> 
>> 
>>> On Nov 5, 2018, at 10:06 AM, Ernest Burghardt  wrote:
>>> 
>>> geode-native should be ready to go now
>>> 
 On Tue, Oct 30, 2018 at 2:56 PM Dave Barnes  wrote:
 
 unix_index.html and win_index.html cannot simply be removed, as they're
 referenced by Cmake. I created a ticket to address this:
 https://issues.apache.org/jira/browse/GEODE-5958.
 
> On Tue, Oct 30, 2018 at 11:48 AM Dave Barnes  wrote:
> 
> Re: the docs links mentioned in Anthony's message:
> 
> docs/README.md - the reference to the Geode CONTRIBUTE.md file is useful.
> I think we can assume that a user of the geode-native API will have a
 Geode
> installation, too.
> docs/api/unix_index.html and docs/api/win_index.html - These files (and
> their bad links) are no longer needed and can be removed.
> 
>> On Tue, Oct 30, 2018 at 7:48 AM Anthony Baker  wrote:
>> 
>> I ran rat manually and got this:
>> 
>> Files with unapproved licenses:
>> 
>> /geode/.cpackignore
>> /geode/.lcovrc
>> /geode/clicache/src/native_shared_ptr.hpp
>> /geode/templates/security/CMakeLists.txt.forInstall
>> 
>> Shouldn’t these failures be causing travis to fail?
>> 
>> Many of the files rat that marks as binary have this the annoying BOM
 [1]
>> from visual studio.  Seems like we should just remove those.  That will
>> reveal a number of files that need a license header.
>> 
>> What is this file?  Seems to be binary content:
>>  clicache/test/native_shared_ptrTests.cpp
>> 
>> I also noticed this text that should be updated to point to where we
>> intend to host the documentation (on the geode website):
>> 
>> docs/README.md:The Geode-Native repository provides the full source for
>> the Apache Geode Native Client User Guide in markdown format (see
>> _geode-project-dir_/geode-docs/CONTRIBUTE.md for more information on
 how to
>> use markdown in this context). Users can build the markdown into an HTML
>> user guide using [Bookbinder](https://github.com/pivotal-cf/bookbinder)
>> and the instructions below.
>> docs/api/unix_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
>> target="_blank">Pivotal GemFire Native Client Documentation.
>> docs/api/win_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io";
>> target="_blank">Pivotal GemFire Native Client Documentation.
>> 
>> 
>> Anthony
>> 
>> [1] https://en.wikipedia.org/wiki/Byte_order_mark
>> 
>>> On Oct 29, 2018, at 12:11 PM, Jacob Barrett 
>> wrote:
>>> 
>>> There are a lot of files that rat is seeing as binary files and
 ignoring
>>> the headers. Many of those files are not binary. Perhaps they have the
>>> wrong metadata associated with them in git as a result of bad commits.
>> We
>>> should clean all those files up so that rat is checking everything
>>> correctly.
>>> 
 On Thu, Oct 18, 2018 at 3:41 PM Dan Smith  wrote:
 
 Following up on this - is there anything we still need to do before
 we
>> cut
 the 1.8 release branch in 2 weeks?
 
 Overall I think the native client source code looks like it's in good
>> shape
 - we're running rat, the LICENSE and NOTICE look good, no binaries in
>> the
 source, etc.
 
 For cutting the release branch, do we have criteria other than
 passing
 travis [1] ?
 What will our release steps should look like for the native client -
>> just
 tar up the source and sign it with gpg?
 
 If we can have this figured out ahead of time and at least
>> provisionally
 added to the release steps [2] I think it will help this release go a
 little smoother.
 
 [1] https://travis-ci.org/apache/geode-native/branches
 [2]
 
>> 
 https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
 
> On Thu, Oct 11, 2018 at 3:23 PM Dan Smith  wrote:
> 
> +1 for a source release. Awesome!
> 
> -Dan
> 
> On Thu, Oct 11, 2018 a

[DISCUSS] including Java11 in the pipelines

[Owen Nichols]

Now that tests are passing under Java 11, it was recommended last week to make 
Java 11 tests gating for the develop pipeline.  [Fyi, Windows tests are not yet 
gating, meaning the pipeline will success and publish artifacts even if a 
Windows tests fails.]

Three topics merit discussion:

1) For the Geode 1.8 release, should the release notes advertise “experimental 
support for Java 11” or no support?  If the latter, should Java 11 tests still 
be gating on the 1.8 release branch, or only on develop?

2) As of now, pre-checkin runs tests only against Java8.  Now that Java11 is 
gating in develop, should we now be testing against both Java8 and Java11 as 
part of validating pull requests?

3) In the develop pipeline, should non-gating jobs continue to be run in 
parallel with gating jobs?  Or would it be better to change the develop 
pipeline to only run the non-gating tests after all gating jobs have passed?

Thanks,
-Owen

P.S. after a brief trial of combining Java8 and Java11 tests into a single 
pipeline job, that was reverted and it looks like separate jobs are here to 
stay.  Combined jobs made it difficult to look at dual scrolling outputs and 
dual archive-results steps.  If you feel there’s a better solution, please 
speak up.  

[PROPOSAL] New WAN callback API & Dead-letter queue example

[Diane Hardman]

WAN replication allows 2 remote data centers to maintain consistency across
their data regions. There are circumstances when one data center cannot
successfully process incoming events delivered over the WAN gateway and an
exception is sent back to the sending data center along with the
acknowledgment.

This proposal is to add a callback API to the Gateway Sender that will be
executed when an exception is returned from the Gateway Receiver.

Please review the following Wiki page containing more details and give us
your feedback.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80452478

November 2018 Board Report Volunteer

[Anthony Baker]

We need to prepare a report for the ASF Board by Nov 14.  Any volunteers to 
write up a draft?

You can review the last report [1] and use the report generator [2] to 
auto-fill some sections (if you have committer status).

Anthony

[1] https://whimsy.apache.org/board/minutes/Geode.html
[2] https://reporter.apache.org/?geode

Re: November 2018 Board Report Volunteer

[Robert Houghton]

I volunteer as tribute

On Nov 7, 2018 12:42, "Anthony Baker"  wrote:

We need to prepare a report for the ASF Board by Nov 14.  Any volunteers to
write up a draft?

You can review the last report [1] and use the report generator [2] to
auto-fill some sections (if you have committer status).

Anthony

[1] https://whimsy.apache.org/board/minutes/Geode.html
[2] https://reporter.apache.org/?geode

Re: [DISCUSS] including Java11 in the pipelines

[Jinmei Liao]

First of all, I believe all gating tests should be run in precheckin. If we
make jdk11 tests gating, we should make it part of the precheckin. If we
don't put them in precheckin, they should not be gating.

Secondly, If we don't make jdk11 tests gating, soon they will become like
windows tests, people only look at them after it's been failing for days,
which is not good.

Thirdly, for non-gating tests, we probably should run them after all the
gating tests are done.

On Wed, Nov 7, 2018 at 11:39 AM Owen Nichols  wrote:

> Now that tests are passing under Java 11, it was recommended last week to
> make Java 11 tests gating for the develop pipeline.  [Fyi, Windows tests
> are not yet gating, meaning the pipeline will success and publish artifacts
> even if a Windows tests fails.]
>
> Three topics merit discussion:
>
> 1) For the Geode 1.8 release, should the release notes advertise
> “experimental support for Java 11” or no support?  If the latter, should
> Java 11 tests still be gating on the 1.8 release branch, or only on develop?
>
> 2) As of now, pre-checkin runs tests only against Java8.  Now that Java11
> is gating in develop, should we now be testing against both Java8 and
> Java11 as part of validating pull requests?
>
> 3) In the develop pipeline, should non-gating jobs continue to be run in
> parallel with gating jobs?  Or would it be better to change the develop
> pipeline to only run the non-gating tests after all gating jobs have passed?
>
> Thanks,
> -Owen
>
> P.S. after a brief trial of combining Java8 and Java11 tests into a single
> pipeline job, that was reverted and it looks like separate jobs are here to
> stay.  Combined jobs made it difficult to look at dual scrolling outputs
> and dual archive-results steps.  If you feel there’s a better solution,
> please speak up.
>
>

-- 
Cheers

Jinmei

Our use of Jira "Fix Version/s"

[Kirk Lund]

Does anyone have a link to a wiki page describing our use of "Fix
Version/s" on Geode Jira tickets?

My understanding is that when we file a ticket we leave it blank. Then when
we commit a fix to develop we change the Jira ticket to "Resolved" and fill
in the "Fix Version/s" with the upcoming release (ex: 1.8.0). Then when we
release 1.8.0, all tickets that are in "Resolved" with "Fix Version/s" of
1.8.0 will be changed to "Closed" with "Fix Version/s" 1.8.0.

Some of our community are filing tickets with "Fix Version/s" pre-filled
with the version that we hope to fix the ticket in.

Anyone have a definitive answer for this process?

Thanks,
Kirk

Re: Our use of Jira "Fix Version/s"

[Alexander Murmann]

Kirk, I think most of us are in agreement that it works as you are
describing. The notes for the release manager also assume that we are all
following this process.
However, I also was unable to find something obvious in the wiki. The
closest is the "JIRA Guidelines" page
. That
page is pretty implicit about it by just mentioning that you should set the
version as part of completing a story.

It might be nice to have a paragraph somewhere that explains how to file a
JIRA ticket. Where would be a good place(s) that would actually be seen?

On Wed, Nov 7, 2018 at 2:52 PM Kirk Lund  wrote:

> Does anyone have a link to a wiki page describing our use of "Fix
> Version/s" on Geode Jira tickets?
>
> My understanding is that when we file a ticket we leave it blank. Then when
> we commit a fix to develop we change the Jira ticket to "Resolved" and fill
> in the "Fix Version/s" with the upcoming release (ex: 1.8.0). Then when we
> release 1.8.0, all tickets that are in "Resolved" with "Fix Version/s" of
> 1.8.0 will be changed to "Closed" with "Fix Version/s" 1.8.0.
>
> Some of our community are filing tickets with "Fix Version/s" pre-filled
> with the version that we hope to fix the ticket in.
>
> Anyone have a definitive answer for this process?
>
> Thanks,
> Kirk
>