Re: Review Request 53813: GEODE-2114 Revise user and password options to gfsh connect

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53813/#review156107
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 16, 2016, 4:29 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53813/
> ---
> 
> (Updated Nov. 16, 2016, 4:29 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Note that the password is clear text.
> - State that user and password are used for authentication.
> 
> 
> Diffs
> -
> 
>   geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb 
> c015cfe89b702064f70a8aa21c4e628c898d444f 
> 
> Diff: https://reviews.apache.org/r/53813/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53750: GEODE-2110 Add gfsh start server user and password options

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53750/#review155877
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 15, 2016, 1:55 a.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53750/
> ---
> 
> (Updated Nov. 15, 2016, 1:55 a.m.)
> 
> 
> Review request for geode, Dave Barnes, Jinmei Liao, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Modifies gfsh start server command reference page to add
> the two missing options: --user and --password
> 
> 
> Diffs
> -
> 
>   geode-docs/tools_modules/gfsh/command-pages/start.html.md.erb 
> 06dfce4d6a96f64295a069a50d79d55b87a1da67 
> 
> Diff: https://reviews.apache.org/r/53750/diff/
> 
> 
> Testing
> ---
> 
> 1. bundle exec bookbinder bind local   finds no broken links
> 
> 2. gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53737: GEODE-2101 Improve WAN topology terminology in docs

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53737/#review155864
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 14, 2016, 8:16 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53737/
> ---
> 
> (Updated Nov. 14, 2016, 8:16 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The terms parallel and serial are not right, so change
> them:
> - a parallel multi-site topology is a fully connected
> mesh
> - a serial multi-site topology is a ring
> 
> 
> Diffs
> -
> 
>   
> geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb
>  4b5753b7e32423ab3e1f1d7ad6647465ed378ce9 
> 
> Diff: https://reviews.apache.org/r/53737/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53746: GEODE-2105 Remove docs about log collection utility

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53746/#review155863
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 14, 2016, 11:02 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53746/
> ---
> 
> (Updated Nov. 14, 2016, 11:02 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The log collection utility is not part of the release,
> so remove the documentation.  The content removed by
> this commit has been placed on the feature/GEODE-79 branch.
> 
> 
> Diffs
> -
> 
>   geode-book/master_middleman/source/subnavs/geode-subnav.erb 
> 959fdf32953b7f6d079dfa092ca6f8a1d0e69438 
>   geode-docs/managing/logging/log_collection_utility.html.md.erb 
> e83634f4082996d67497d92a943671f0e81b6abc 
>   geode-docs/managing/logging/logging.html.md.erb 
> db4de7ea904f9833e7b06800af597ec2634b5c56 
> 
> Diff: https://reviews.apache.org/r/53746/diff/
> 
> 
> Testing
> ---
> 
> 1. bundle exec bookbinder bind local, with bookbinder version 10.0.2 does not 
> find any broken links
> 
> 2. gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53661: GEODE-2094 Update admin/dev REST API documentation

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53661/#review155668
---



I noticed one variation to the pattern: In 
geode-docs/rest_apps/setup_config.html.md.erb at line 100, did you miss one 
conversion of start-dev-rest-api to start-rest-api, or was this intentional?

- Dave Barnes


On Nov. 10, 2016, 10:44 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53661/
> ---
> 
> (Updated Nov. 10, 2016, 10:44 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Jinmei Liao, Joey McAllister, and 
> Kevin Duling.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Add 3 missing gfsh start server options:
>   --http-service-port
>   --http-service-bind-address
>   --start-rest-api
> 
> - Update examples to use these options, instead of using
> the older --J=-gemfire. specification.
> 
> 
> Diffs
> -
> 
>   geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb 
> c8ea24096c76a5c03bd7a902d225ee4566932b29 
>   geode-docs/rest_apps/setup_config.html.md.erb 
> 604dd059290f8da41e2e05e0946e6a7eaa01e6ca 
>   geode-docs/tools_modules/gfsh/command-pages/start.html.md.erb 
> ff703cb4a7fc49a1bffa92cf9cc2207a6cce2d32 
> 
> Diff: https://reviews.apache.org/r/53661/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53637: GEODE-2090 Update off-heap statistics documentation

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53637/#review155537
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 10, 2016, 12:46 a.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53637/
> ---
> 
> (Updated Nov. 10, 2016, 12:46 a.m.)
> 
> 
> Review request for geode, Dave Barnes, Darrel Schneider, Joey McAllister, and 
> Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - add/correct the gfsh show metrics command reference
> page to include the offheap category for when the member
> is specified
> - in the list of OffHeapMemoryStats, correct the name of
> a statistic:  compactions should be defragmentations
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/statistics/statistics_list.html.md.erb 
> 02ed6a783eb6ff01c0897c9f25244bb1cef9d33b 
>   geode-docs/tools_modules/gfsh/command-pages/show.html.md.erb 
> 98009f1cfb413b3d2111944d9d58bbbace625ccf 
> 
> Diff: https://reviews.apache.org/r/53637/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> java class that has the names of the OffHeapMemoryStats is
> geode-core/src/main/java/org/apache/geode/internal/offheap/OffHeapStorage.java
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53581: GEODE-2070 Improve documentation of region management

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53581/#review155329
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 8, 2016, 6:53 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53581/
> ---
> 
> (Updated Nov. 8, 2016, 6:53 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2070 Improve documentation of region management
> 
> 
> Diffs
> -
> 
>   geode-book/master_middleman/source/subnavs/geode-subnav.erb 
> 0f1292c23bfe6222c808f84f19e3ac78cf69a635 
>   geode-docs/basic_config/data_regions/chapter_overview.html.md.erb 
> 4917259e06345a8e6fc9ad56fc8045961e151fd5 
>   geode-docs/basic_config/data_regions/create_a_region_with_API.html.md.erb 
> 8bb359b86a0eaeb88fa6fef8432bef89aa872a8b 
>   
> geode-docs/basic_config/data_regions/create_a_region_with_cacheXML.html.md.erb
>  d7838f64f4ed462c26a801911bfe7948891760e0 
>   geode-docs/basic_config/data_regions/managing_data_regions.html.md.erb 
> f4f792eae3a60efaa52d782f9fc0751656ccf58f 
>   geode-docs/reference/topics/cache_xml.html.md.erb 
> 8d3187b49eff8197f153d6832dc522ce503b1027 
>   geode-docs/reference/topics/chapter_overview_regionshortcuts.html.md.erb 
> 85c69e7c52b03b93efd8ce7be6be698935560fac 
>   geode-docs/reference/topics/client-cache.html.md.erb 
> 963f57434e488c89749163408848b27f714beabd 
>   geode-docs/reference/topics/gfe_cache_xml.html.md.erb 
> 2cd78ec933277fc2be05bb3021bced32a5034192 
> 
> Diff: https://reviews.apache.org/r/53581/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: [VIRTUAL] Geode Clubhouse Thurs, November 10 9AM Pacific - Best Practices for Testing Geode, or any Java Open Source Project

[Dave Barnes]

Thanks for organizing these sessions, Greg. Please check the date -
Thursday is the 10th, Friday is the 11th.

On Mon, Nov 7, 2016 at 3:22 PM, Gregory Chase  wrote:

> Dear Geode Community,
>
> Its been a while since we've had a contributor's topic.  We have a great
> discussion planned for this Thursday, November 11, at 9AM Pacific: "*Best
> Practices for Testing Geode, or any Java open source project*."
>
> Add to calendar
>  cXRpNm45cXFhdjRmY2d2dDNlNHVlYnZqY3MgcGl2b3RhbC5pb191OGtndnVh
> aGprYm9oMWduZmh2NXRzMnY5Y0Bn=America/Los_Angeles>
> | Join the meeting 
>
> Kirk Lund, Committer for Apache Geode, will discuss the following:
>
> Unit testing -  how contributors and committers should be testing new code
> to be added to Apache Geode.
> Integration testing - the testing framework that runs for automatic builds
> Distributed testing - Geode-specific testing built upon JUnit, known as
> DUnit
>
> Lastly Kirk would like to talk about a possible future for DUnit to allow
> Geode users to test their scale-out applications based on Geode.
>
> *About the speaker*
> Kirk Lund is a software engineer with more than two decades experience
> developing and testing highly concurrent, distributed enterprise software.
> Kirk has been working with the Apache Geode and GemFire technology for well
> over a decade.
>
> See you this coming Thursday!
>
> Add to calendar
>  cXRpNm45cXFhdjRmY2d2dDNlNHVlYnZqY3MgcGl2b3RhbC5pb191OGtndnVh
> aGprYm9oMWduZmh2NXRzMnY5Y0Bn=America/Los_Angeles>
>  | Join the meeting 
>
> --
> Greg Chase
>
> Global Head, Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Re: Review Request 53444: GEODE-2068 Improve documentation on serial/parallel gateway senders

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53444/#review154964
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 4, 2016, 12:11 a.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53444/
> ---
> 
> (Updated Nov. 4, 2016, 12:11 a.m.)
> 
> 
> Review request for geode, Barry Oglesby, Dave Barnes, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2068 Improve documentation on serial/parallel gateway senders
> 
> 
> Diffs
> -
> 
>   
> geode-docs/topologies_and_comm/topology_concepts/multisite_overview.html.md.erb
>  2ad9a3843fe78931e1cb802c6c0a2fcb4569dc74 
> 
> Diff: https://reviews.apache.org/r/53444/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53434: GEODE-2060 Update docs for security-related poperties

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53434/#review154752
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 3, 2016, 4:24 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53434/
> ---
> 
> (Updated Nov. 3, 2016, 4:24 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Jinmei Liao, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Add security-manager and security-post-processor.
> Deprecate others:
>   security-client-accessor
>   security-client-accessor-pp
>   security-client-authenticator
>   security-peer-auth-init
>   security-peer-authenticator
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/topics/gemfire_properties.html.md.erb 
> ae0f198b1f765469801958e0f7854b54b803b003 
> 
> Diff: https://reviews.apache.org/r/53434/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53414: GEODE-2065 Document defragmentationsInProgress statistic

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53414/#review154741
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 2, 2016, 11:52 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53414/
> ---
> 
> (Updated Nov. 2, 2016, 11:52 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Darrel Schneider, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a sub-task of GEODE-1590.
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/statistics/statistics_list.html.md.erb 
> 07e4281f239b73896ed7b1b2fbb6429c87ac5024 
> 
> Diff: https://reviews.apache.org/r/53414/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53331: GEODE-2047 Document change to enable-network-partition-detection

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53331/#review154415
---


Ship it!




Ship It!

- Dave Barnes


On Nov. 1, 2016, 4:02 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53331/
> ---
> 
> (Updated Nov. 1, 2016, 4:02 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Dave Barnes, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - This is a subtask of GEODE-762.
> - The default value of property enable-network-partition-detection
> changed from false to true, enabling partition detection by
> default, so all documentation that discusses partition detection
> also needs to change.
> - Fixed a minor typo or two encountered in the files that were
> being updated.
> 
> 
> Diffs
> -
> 
>   
> geode-docs/managing/troubleshooting/recovering_conflicting_data_exceptions.html.md.erb
>  38375aea1e5742d878d1e7dbaf3c92d67320d17f 
>   
> geode-docs/managing/troubleshooting/recovering_from_network_outages.html.md.erb
>  8c23beac365af0f8f917b13447c2ae6382ad2525 
>   geode-docs/reference/topics/gemfire_properties.html.md.erb 
> 988256840a084cac56a4e38723415a4c4ea2d99f 
> 
> Diff: https://reviews.apache.org/r/53331/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53311: GEODE-2045 Improve docs of region shortcuts

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53311/#review154308
---


Ship it!




Ship It!

- Dave Barnes


On Oct. 31, 2016, 7:28 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53311/
> ---
> 
> (Updated Oct. 31, 2016, 7:28 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Make sure that partitioned regions do not say or imply
> that they have local scope.
> - Fix labels with anchors, such that links work.
> - Remove reference links to general descriptions of the
> attributes used by the shortcuts.
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/topics/region_shortcuts_reference.html.md.erb 
> d5cb2fabdf8f8ce56b3bbf5dbf4706bb19e0742d 
>   geode-docs/reference/topics/region_shortcuts_table.html.md.erb 
> c0ead67b475742b05282b9f32df6e10296d94714 
> 
> Diff: https://reviews.apache.org/r/53311/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: GEODE-2036 and documentation practices and procedures

[Dave Barnes]

3. If there's no hard-and-fast rule for *always* associating a JIRA with
every change, then I agree with Anthony and Dan for typos and small changes.

On Wed, Oct 26, 2016 at 9:19 AM, Dan Smith  wrote:

> 1) +1
> 2) +1
>
> 3)
> > I don’t see much value in creating an uber-JIRA for tracking minor doc
> changes.  Why not skip it entirely?
> I agree with Anthony on this one, there's not much value in having some
> catch all JIRA for unrelated changes.
>
> -Dan
>
> On Tue, Oct 25, 2016 at 7:08 PM, Anthony Baker  wrote:
>
> > What I _think_ you are suggesting is using C-T-R (commit-then-review) [1]
> > for reasonably well-defined documentation-related changes.  Do you agree?
> >
> > Here’s why we tag commits with a JIRA:
> >
> > - we can better understand the reason for a code change by looking at the
> > associated JIRA
> > - we can scope work in/out of a release by using ‘Fix version’ on the
> JIRA
> > - we can generate release notes by looking at resolved issues for a given
> > version
> >
> > I don’t see much value in creating an uber-JIRA for tracking minor doc
> > changes.  Why not skip it entirely?
> >
> >
> > Anthony
> >
> > [1] https://www.apache.org/foundation/glossary.html#CommitThenReview <
> > https://www.apache.org/foundation/glossary.html#CommitThenReview>
> >
> >
> > > On Oct 25, 2016, at 5:45 PM, Karen Miller  wrote:
> > >
> > > With our documentation now in the same repository as the code, there
> are
> > now
> > > some doc-related issues that could use some community consensus. Here
> are
> > > some of my opinions to start the discussion.
> > >
> > > 1. Create new JIRA tickets for each documentation task, or use the
> > existing
> > > ticket under
> > > which the code is committed for the documentation task?
> > >
> > >  I'd like to see a combination of both, but use the existing ticket
> > > wherever
> > > possible. By using the same ticket as the code, the documentation
> effort
> > is
> > > less
> > > likely to be forgotten.  I certainly think that when a new property is
> > > introduced,
> > > or a default value is changed, the same ticket can be used.
> > >
> > >  I think that for large, and new efforts (in the documentation), new
> > > tickets are the
> > > way to go.
> > >
> > > 2. Do we need a review effort for all documentation tasks?
> > >
> > >  My opinion:  no, not for everything.  The bigger the changes, the more
> > > likely that
> > > a review is warranted.
> > >
> > > 3. Do we need a new JIRA ticket for each very little documentation
> > change?
> > >
> > >  On this question, my strong opinion is no, we don't need distinct
> JIRAs.
> > > I'd like to propose that we use a single ticket per release that
> > > all typo fixes and really small changes are committed under.  No
> > > reviews needed. We won't end up with dozens of tickets, each for a tiny
> > > change that really needs no community discussion.  If the ticket
> becomes
> > > abused,
> > > we can revisit the topic.
> > >
> > >  I've already created https://issues.apache.org/jira/browse/GEODE-2036
> > for
> > > just this purpose, as I have a typo that I want to fix.  If no one
> > objects,
> > > we can
> > > use this ticket for all tiny fixes that go with Geode 1.1.0.
> >
> >
>

Re: GEODE-2036 and documentation practices and procedures

[Dave Barnes]

1. +1 with a guideline:

If code and docs share a JIRA ticket, the ticket cannot (or at least should
not) be closed until both parts are complete. In some cases both tasks
finish around the same time, so a shared ticket is fine.

But there are cases where code is completed before docs (as with bug fixes
where the developer doesn't realize there's a doc impact until after the
code has been repaired) or where docs finish before code (as is
historically true with deprecations). In cases where the two tasks don't
finish near the same time, I prefer separate tickets with a connection in
JIRA. This can usually take the form of a doc ticket labeled as a 'subtask'
to the code ticket. That way neither effort prevents the other from
declaring victory and moving forward.

2. +1
3. +1


On Tue, Oct 25, 2016 at 6:14 PM, William Markito 
wrote:

> 1. +1
> 2. +1  - Reason and common sense should apply...
> 3. +1
>
> On Tue, Oct 25, 2016 at 6:03 PM, Joey McAllister 
> wrote:
>
> > Thanks for kicking this off, Karen!
> >
> > 1. +1 - I like the idea of making documentation part of the requirements
> > for issues that need it. Is it better in these cases to use the primary
> > ticket or to create a new subticket associated with the primary one?
> >
> > 2. +1 - I agree that reviews should be on a case-by-case basis. Since the
> > community has committers/contributors who specialize in technical
> > documentation, I'd hope that those docs specialists would make themselves
> > available for such reviews. And, on the flip side, I'd hope that anyone
> > focused on adding/editing documentation based on new/changed code would
> > seek the review of the developer who worked on the code. And, yes
> > (connected to #3 below), I think small changes might not need reviews at
> > all.
> >
> > 3. +1
> >
> > On Tue, Oct 25, 2016 at 5:47 PM Karen Miller  wrote:
> >
> > > With our documentation now in the same repository as the code, there
> are
> > > now
> > > some doc-related issues that could use some community consensus. Here
> are
> > > some of my opinions to start the discussion.
> > >
> > > 1. Create new JIRA tickets for each documentation task, or use the
> > existing
> > > ticket under
> > > which the code is committed for the documentation task?
> > >
> > >   I'd like to see a combination of both, but use the existing ticket
> > > wherever
> > > possible. By using the same ticket as the code, the documentation
> effort
> > is
> > > less
> > > likely to be forgotten.  I certainly think that when a new property is
> > > introduced,
> > > or a default value is changed, the same ticket can be used.
> > >
> > >   I think that for large, and new efforts (in the documentation), new
> > > tickets are the
> > > way to go.
> > >
> > > 2. Do we need a review effort for all documentation tasks?
> > >
> > >   My opinion:  no, not for everything.  The bigger the changes, the
> more
> > > likely that
> > > a review is warranted.
> > >
> > > 3. Do we need a new JIRA ticket for each very little documentation
> > change?
> > >
> > >   On this question, my strong opinion is no, we don't need distinct
> > JIRAs.
> > > I'd like to propose that we use a single ticket per release that
> > > all typo fixes and really small changes are committed under.  No
> > > reviews needed. We won't end up with dozens of tickets, each for a tiny
> > > change that really needs no community discussion.  If the ticket
> becomes
> > > abused,
> > > we can revisit the topic.
> > >
> > >   I've already created https://issues.apache.org/
> jira/browse/GEODE-2036
> > > for
> > > just this purpose, as I have a typo that I want to fix.  If no one
> > objects,
> > > we can
> > > use this ticket for all tiny fixes that go with Geode 1.1.0.
> > >
> >
>
>
>
> --
>
> ~/William
>

Re: [DISCUSS] Graduation

[Dave Barnes]

+1

On Tue, Oct 25, 2016 at 6:00 PM, Jared Stewart  wrote:

> +1
>
> On Oct 25, 2016 5:58 PM, "Dan Smith"  wrote:
>
> > +1
> >
> > -Dan
> >
> > On Tue, Oct 25, 2016 at 5:43 PM, Joey McAllister  >
> > wrote:
> >
> > > +1
> > >
> > > On Tue, Oct 25, 2016 at 5:42 PM Anthony Baker 
> wrote:
> > >
> > > > +1
> > > >
> > > > > On Oct 25, 2016, at 5:25 PM, Roman Shaposhnik 
> > wrote:
> > > > >
> > > > > Unless somebody objects strongly to my #2 and #3 proposals I'm
> going
> > > > > to kick of this thread on private@.
> > > >
> > > >
> > >
> >
>

Review Request 53107: GEODE-2023: Add Lucene documentation

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53107/
---

Review request for geode, Joey McAllister and Karen Miller.


Repository: geode


Description
---

GEODE-2023: Add Lucene documentation


Diffs
-

  geode-book/master_middleman/source/subnavs/geode-subnav.erb 
2373f4b397952372a61923c5b57ef8f6d2102ee3 
  geode-docs/tools_modules/book_intro.html.md.erb 
852e3c9de6eba2f83f0c513912c53b771889509e 
  geode-docs/tools_modules/lucene_integration.html.md.erb PRE-CREATION 

Diff: https://reviews.apache.org/r/53107/diff/


Testing
---


Thanks,

Dave Barnes

Re: Review Request 53072: GEODE-2019 Add automated rebalance documentation

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53072/#review153472
---


Ship it!




Ship It!

- Dave Barnes


On Oct. 20, 2016, 9:22 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53072/
> ---
> 
> (Updated Oct. 20, 2016, 9:22 p.m.)
> 
> 
> Review request for geode, Dave Barnes and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2019  Add automated rebalance documentation
> 
> 
> Diffs
> -
> 
>   geode-docs/developing/partitioned_regions/automated_rebalance.html.md.erb 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53072/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Hosting the docs (was Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2)

[Dave Barnes]

Following up - I gave the plugin a good try, had some help from Dan. No
luck getting it to run correctly. (It was last updated a couple of years
ago.)
Will pursue some other avenues.


On Tue, Oct 18, 2016 at 3:59 PM, William Markito 
wrote:

> With the docs now in markdown format, it should also be easy to convert
> markdown to PDF.  Here is a gradle plugin that can do that for example...
>
> https://github.com/sleroy/gradle-doc-plugin
>
> On Tue, Oct 18, 2016 at 1:49 PM, John Blum  wrote:
>
> > Perhaps longer term we should consider moving the docs to Asciidoc  It is
> > relatively simple matter to convert Asciidoc to PDF.
> >
> > On Tue, Oct 18, 2016 at 1:42 PM, Jared Stewart 
> > wrote:
> >
> > > Sadly just looked at the license for wkhtmltopdf and it uses GPL 3.0.
> I
> > > believe that would be an issue as discussed here <
> > https://www.apache.org/
> > > licenses/GPL-compatibility.html>.
> > >
> > > > On Oct 18, 2016, at 1:38 PM, Jared Stewart 
> > wrote:
> > > >
> > > > In the past I have used wkhtmltopdf to build programmatically PDFs
> from
> > > HTML documents.  We could try using this to generate a PDF version of
> the
> > > docs in the interim until we can generate a PDF directly from book
> > binder.
> > > >
> > > >> On Oct 18, 2016, at 1:09 PM, Michael Stolz 
> wrote:
> > > >>
> > > >> Its really important to ship pdf docs because its very difficult to
> > > search
> > > >> otherwise.
> > > >>
> > > >> --
> > > >> Mike Stolz
> > > >> Principal Engineer, GemFire Product Manager
> > > >> Mobile: 631-835-4771
> > > >>
> > > >> On Tue, Oct 18, 2016 at 12:49 PM, Joey McAllister <
> > > jmcallis...@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> @Dan: I didn't realize there was a docs link in the top-level
> README.
> > > We
> > > >>> can change that for the next release, and I can look into
> redirecting
> > > >>> geode.docs.pivotal.io to geode.incubator.apache.org/docs/ in the
> > > meantime,
> > > >>> once the docs are posted there..
> > > >>>
> > > >>> @William: We don't currently have a PDF for these docs. I'm
> > researching
> > > >>> options.
> > > >>>
> > > >>> On Mon, Oct 17, 2016 at 6:53 PM William Markito <
> wmark...@pivotal.io
> > >
> > > >>> wrote:
> > > >>>
> > > >>> IHMO, it would be really nice to ship a PDF version of the docs.
> > > >>>
> > > >>> About the examples, if we could package and ship sources only for
> > that
> > > >>> module, that would be cool as well.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Mon, Oct 17, 2016 at 5:21 PM, Dan Smith 
> > wrote:
> > > >>>
> > >  Along these lines, should we distributing the docs with the binary
> > > >>> release?
> > >  Or maybe just providing a link to them? The README.md shipped with
> > > >>> 1.0.RC2
> > >  points to http://geode.docs.pivotal.io/ .
> > > 
> > >  What about geode-examples? Should that be part of the binary
> > release?
> > > 
> > >  -Dan
> > > 
> > >  On Mon, Oct 17, 2016 at 2:21 PM, Joey McAllister <
> > > jmcallis...@pivotal.io
> > > 
> > >  wrote:
> > > 
> > > > @Roman: Nothing that I can think of, apart from giving the
> > community
> > > >>> time
> > > > to offer feedback here (which, it looks like, is all positive).
> > > William
> > > > Markito and I were able to build and test a local version of the
> > > >>> website
> > > > with the docs included.
> > > >
> > > > Based on the +1s here, I'd like to go ahead and push the current
> > docs
> > > >>> to
> > > > the website. I'll also document the process in a README.
> > > >
> > > > On Mon, Oct 17, 2016 at 12:49 PM Roman Shaposhnik <
> > > >>> ro...@shaposhnik.org>
> > > > wrote:
> > > >
> > > >> On Mon, Oct 17, 2016 at 10:57 AM, Anthony Baker <
> > aba...@pivotal.io>
> > > > wrote:
> > > >>> Since the geode docs have now been merged to the develop
> branch,
> > >  let’s
> > > >> start
> > > >>> hosting them on http://geode.apache.org.  Thoughts?
> > > >>
> > > >> Huge +1! Anything stopping you from pushing the first update and
> > > >>> start
> > > >> maintaining
> > > >> it a'la Hadoop:
> > > >>   https://hadoop.apache.org/docs/
> > > >> ?
> > > >>
> > > >> Thanks,
> > > >> Roman.
> > > >>
> > > >
> > > 
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> ~/William
> > > >>>
> > > >
> > >
> > >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
> >
>
>
>
> --
>
> ~/William
>

Re: jvsd

[Dave Barnes]

Hi Dor,
JVSD is in the Geode Repo on a feature branch, feature/GEODE-78.
See http://geode.docs.pivotal.io/docs/tools_modules/jvsd.html for details.
-Dave


On Wed, Oct 19, 2016 at 1:43 AM, Dor Ben Dov  wrote:

> Hi,
>
> Where can I get the latest version of it ?
>
>
> Regards,
> Dor
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Hosting the docs (was Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2)

[Dave Barnes]

I'm a fan of PDFs, too, for their searchability among other things.
There's no process in place, yet, for generating a good-looking PDF from
the Markdown sources. Something to put on the to-do list.
Right now, HTML format is the best presentation.

On Monday, October 17, 2016, William Markito  wrote:

> IHMO, it would be really nice to ship a PDF version of the docs.
>
> About the examples, if we could package and ship sources only for that
> module, that would be cool as well.
>
>
>
> On Mon, Oct 17, 2016 at 5:21 PM, Dan Smith  > wrote:
>
> > Along these lines, should we distributing the docs with the binary
> release?
> > Or maybe just providing a link to them? The README.md shipped with
> 1.0.RC2
> > points to http://geode.docs.pivotal.io/ .
> >
> > What about geode-examples? Should that be part of the binary release?
> >
> > -Dan
> >
> > On Mon, Oct 17, 2016 at 2:21 PM, Joey McAllister  >
> > wrote:
> >
> > > @Roman: Nothing that I can think of, apart from giving the community
> time
> > > to offer feedback here (which, it looks like, is all positive). William
> > > Markito and I were able to build and test a local version of the
> website
> > > with the docs included.
> > >
> > > Based on the +1s here, I'd like to go ahead and push the current docs
> to
> > > the website. I'll also document the process in a README.
> > >
> > > On Mon, Oct 17, 2016 at 12:49 PM Roman Shaposhnik <
> ro...@shaposhnik.org >
> > > wrote:
> > >
> > > > On Mon, Oct 17, 2016 at 10:57 AM, Anthony Baker  >
> > > wrote:
> > > > > Since the geode docs have now been merged to the develop branch,
> > let’s
> > > > start
> > > > > hosting them on http://geode.apache.org.  Thoughts?
> > > >
> > > > Huge +1! Anything stopping you from pushing the first update and
> start
> > > > maintaining
> > > > it a'la Hadoop:
> > > > https://hadoop.apache.org/docs/
> > > > ?
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> >
>
>
>
> --
>
> ~/William
>

Re: GEODE-1466: geode.properties

[Dave Barnes]

PROPERTY_FILE_PREFIX ?

On Thu, Oct 13, 2016 at 3:05 PM, John Blum  wrote:

> -1 for introducing this change as well.
>
> Also -1 for introducing any additional constants/workarounds.  Either fix
> it the way it should be fixed or do nothing at all.
>
> On Thu, Oct 13, 2016 at 2:45 PM, Kirk Lund  wrote:
>
> > -1 at this point I'm against making this change for 1.0.0
> >
> > I'll still work towards fixing GEODE-1466 properly but it'll be fixed on
> > develop within the next week or so.
> >
> > -Kirk
> >
> >
> > On Thu, Oct 13, 2016 at 2:26 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX`
> > or
> > > something more generic that we could use within the Geode.
> > >
> > > Then we could hopefully cover many to most `gemfire` vs `geode`
> renaming.
> > >
> > > But I agree with @Anthony, if we aren't 100% certain about a change
> then
> > > we should hold off until the next release. There is always tomorrow. :D
> > >
> > > --Udo
> > >
> > >
> > >
> > > On 14/10/16 8:05 am, Swapnil Bawaskar wrote:
> > >
> > >> How about introducing a new GEMFIRE_FILE_PREFIX attribute that will
> > >> default
> > >> to "geode" while leaving GEMFIRE_PREFIX default to "gemfire"? Is this
> > >> something that will work?
> > >>
> > >> On Thu, Oct 13, 2016 at 1:48 PM, Anthony Baker 
> > wrote:
> > >>
> > >> Hmmm, you would think it would be easier to change a file name :-)
> > >>>
> > >>> I don’t think we should be pushing destabilizing changes into a
> release
> > >>> branch.  If the changes aren’t ready now we always pick them up for
> the
> > >>> next release.
> > >>>
> > >>> Anthony
> > >>>
> > >>> On Oct 13, 2016, at 1:13 PM, Kirk Lund  wrote:
> > 
> >  I'm currently working with Jared and we have spent a few days
> working
> >  on GEODE-1466. We've been trying to get geode to the point where it
> > can
> >  automatically search for, find and use either geode.properties or
> >  gemfire.properties (preferring geode.properties if both are found).
> > 
> >  We were intending to break this up into three subtasks with the hope
> > of
> >  including #1 in Geode 1.0.0 incubating:
> > 
> >  1) locating geode.properties and gemfire.properties if user has not
> >  specified a specific properties file
> > 
> >  2) support specifying geode configuration properties with system
> > 
> > >>> properties
> > >>>
> >  geode. as well as gemfire.
> > 
> >  ex: -Dgemfire.off-heap-memory-size=40g or
> > -Dgeode.off-heap-memory-size=
> > 
> > >>> 40g
> > >>>
> >  3) modify all other system properties in geode to support alias of
> > 
> > >>> gemfire
> > >>>
> >  as well as geode where the name of the system property currently
> >  contains
> >  gemfire
> > 
> >  ex: -Dgemfire.Query.VERBOSE=true or -Dgeode.Query.VERBOSE=true
> > 
> >  The community is planning to create the Geode 1.0.0 incubating RC
> > 
> > >>> tomorrow.
> > >>>
> >  The work we have completed so far involves modifying geode to search
> > for
> >  both geode.properties and gemfire.properties to use whichever one is
> > 
> > >>> found.
> > >>>
> >  This turns out to be too complex to complete by tomorrow (send me a
> >  email
> >  directly if you want more detailed info which mostly involves
> >  DistributionConfig and ConfigSource).
> > 
> >  In order to complete this in time, we need to use a different
> > strategy.
> >  Instead of looking for geode.properties first and then
> > 
> > >>> gemfire.properties,
> > >>>
> >  we are proposing the following change to DistributionConfig:
> > 
> >  Change the GEMFIRE_PREFIX = "gemfire." constant to be configurable
> by
> > a
> >  system property and change the default to be "geode." This places a
> > 
> > >>> greater
> > >>>
> >  burden on the user who is migrating from GemFire to Geode but
> doesn't
> > 
> > >>> want
> > >>>
> >  to rename gemfire.properties or gemfire system properties. By
> default,
> >  Geode would search for geode.properties unless the user specifies a
> > new
> >  system property with a different prefix ("gemfire."):
> > 
> >  String GEMFIRE_PREFIX = PropertiesPrefix.getGemfireOrGeodePrefix();
> > 
> >  Example of overriding this to be "gemfire.":
> > 
> >  -DgeodePropertiesPrefix="gemfire."
> >  or
> >  -DgeodePropertiesPrefix="gemfire"
> > 
> >  (we'll add the "." for you if you leave it out)
> > 
> >  Pivotal or other vendors could also alter this prefix as they see
> fit.
> > 
> >  There are 453 lines of production code that refer to this
> > GEMFIRE_PREFIX
> >  constant. For example, every system property that contains
> "gemfire."
> > is
> >  currently referring to the constant, so they would also be 

Re: Hibernate module and Geode 1.0 ?

[Dave Barnes]

So, what form should the JIRA ticket assume?
(a) Move HIbernate from develop to a feature branch, or
(b) Merge Hibernate code to develop (as a future task, cf GEODE-1416 for
how the NC was handled)

After somebody (which I can do, if you like) creates a ticket for the code,
I'll create a subtask for moving the accompanying docs.

On Thu, Oct 6, 2016 at 9:34 AM, Joey McAllister 
wrote:

> +1 for moving to a feature branch.
>
> On Thu, Oct 6, 2016 at 9:32 AM Mark Bretl  wrote:
>
> > +1 for feature branch as well.
> >
> > --Mark
> >
> > On Thu, Oct 6, 2016 at 9:30 AM, Dan Smith  wrote:
> >
> > > +1 for moving it to a feature branch.
> > >
> > > -Dan
> > >
> > > On Wed, Oct 5, 2016 at 2:40 PM, Jason Huynh  wrote:
> > > > Bumping to see if we have come to a decision on whether we want to
> move
> > > > this to a feature branch and get rid of it for 1.0 or post 1.0,
> > > especially
> > > > now that the 1.0 release branch has been cut
> > > >
> > > > On Fri, Sep 23, 2016 at 5:22 PM Anthony Baker 
> > wrote:
> > > >
> > > > Likewise!  Geode provides an L2 cache for Hibernate.  That is, an
> > > > application that is using Hibernate could plug in Geode for caching.
> > > > Specifically, we implement Hibernate’s cache interfaces like
> > > CacheProvider,
> > > > RegionFactory, etc.
> > > >
> > > > There are build-time dependencies on several hibernate jars
> > > > (hibernate-annotations, hibernate-core,
> hibernate-commons-annotations).
> > > No
> > > > hibernate source code or jars are shipped with any release.
> > > >
> > > > Docs:
> > > > http://geode.docs.pivotal.io/docs/tools_modules/hibernate_
> > > cache/chapter_overview.html
> > > >
> > > > Code:
> > > > https://git-wip-us.apache.org/repos/asf?p=incubator-geode.
> > > git;a=tree;f=extensions/geode-modules-hibernate;h=
> > > be8b9355934f824b9d4565ec6bfaa5d17a117f45;hb=HEAD
> > > >
> > > > ~/working/apache-geode-1.0.0-incubating.M3$ unzip -l
> > > > tools/Modules/Apache_Geode_Modules-1.0.0-incubating.M3-Hibernate.zip
> > > > Archive:
> > > > tools/Modules/Apache_Geode_Modules-1.0.0-incubating.M3-Hibernate.zip
> > > >   Length Date   TimeName
> > > >     
> > > > 0  08-01-16 17:01   lib/
> > > >114497  08-01-16 16:58   lib/geode-modules-1.0.0-
> incubating.M3.jar
> > > > 56960  08-01-16 17:01
> > > >  lib/geode-modules-hibernate-1.0.0-incubating.M3.jar
> > > >     ---
> > > >171457   3 files
> > > >
> > > > ~/working/apache-geode-1.0.0-incubating.M3$ jar tvf
> > > > lib/geode-modules-hibernate-1.0.0-incubating.M3.jar
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 META-INF/
> > > >139 Mon Aug 01 17:01:40 PDT 2016 META-INF/MANIFEST.MF
> > > >  28210 Mon Jul 25 21:52:24 PDT 2016 META-INF/LICENSE
> > > >584 Fri Jul 08 12:51:12 PDT 2016 META-INF/NOTICE
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 com/
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/modules/
> > > >  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/modules/
> > > hibernate/
> > > >   1210 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/EnumType.class
> > > >   5707 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/GemFireCache.class
> > > >   1700 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/GemFireCacheListener.class
> > > >   7084 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/GemFireCacheProvider.class
> > > >   1104 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/
> GemFireQueryCacheFactory.class
> > > >   9529 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/GemFireRegionFactory.class
> > > >  0 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/
> > > >   1020 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/Access$1.class
> > > >   9535 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/Access.class
> > > >343 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/
> > > ClientServerRegionFactoryDelegate$1.class
> > > >   1508 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/
> > > ClientServerRegionFactoryDelegate$LocatorHolder.class
> > > >   9639 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/
> > > ClientServerRegionFactoryDelegate.class
> > > >   9739 Mon Aug 01 17:01:40 PDT 2016
> > > > com/gemstone/gemfire/modules/hibernate/internal/
> CollectionAccess.class
> > > >   2409 Mon Aug 01 17:01:40 PDT 2016
> > > >
> > 

Re: Geode docs: location of donated source files

[Dave Barnes]

Thanks, everyone, for the clarifications.
I consolidated the doc donation files under a single directory called
'geode-docs' on branch feature/GEODE-1952.


On Mon, Oct 3, 2016 at 11:26 AM, Dave Barnes <dbar...@pivotal.io> wrote:

> That sounds like the end result I was hoping for.
>
> On Mon, Oct 3, 2016 at 10:05 AM, Dan Smith <dsm...@pivotal.io> wrote:
>
>> Sorry, yes, I meant a new geode-docs subdirectory.
>>
>> -Dan
>>
>> On Sat, Oct 1, 2016 at 5:12 PM, Anthony Baker <aba...@pivotal.io> wrote:
>>
>>> Did you mean a new top-level dir (e.g. geode-docs) or a subdir of
>>> geode-core?  Since the docs could cover multiple components I’m not sure it
>>> makes sense to put them under geode-core.
>>>
>>> Anthony
>>>
>>>
>>> >
>>> > I think we should just go ahead and create a feature branch off of the
>>> the
>>> > current geode develop and merge these changes in as a geode-core
>>> > subdirectory. We could start the work of cleaning up the build
>>> > instructions, etc. right away on that feature branch.
>>> >
>>> > -Dan
>>> >
>>>
>>>
>>
>

Re: Geode docs: location of donated source files

[Dave Barnes]

That sounds like the end result I was hoping for.

On Mon, Oct 3, 2016 at 10:05 AM, Dan Smith  wrote:

> Sorry, yes, I meant a new geode-docs subdirectory.
>
> -Dan
>
> On Sat, Oct 1, 2016 at 5:12 PM, Anthony Baker  wrote:
>
>> Did you mean a new top-level dir (e.g. geode-docs) or a subdir of
>> geode-core?  Since the docs could cover multiple components I’m not sure it
>> makes sense to put them under geode-core.
>>
>> Anthony
>>
>>
>> >
>> > I think we should just go ahead and create a feature branch off of the
>> the
>> > current geode develop and merge these changes in as a geode-core
>> > subdirectory. We could start the work of cleaning up the build
>> > instructions, etc. right away on that feature branch.
>> >
>> > -Dan
>> >
>>
>>
>

Geode docs: location of donated source files

[Dave Barnes]

Please help me understand the source-control setup for the donated Geode
docs.
Per the announcement:
> The donated source currently sits in a separate branch in the Geode
repository named staging/docs-grant1

I see when I check out the staging branch that the dozen or so user manual
source directories are located at the topmost level of the repo,
interspersed with source code directories. Another four individual files
are placed at the top level, also, including a README.md that overwrites
the README.md for the Geode code that I see when I'm working on the develop
branch.

I think it would be easier to find the files and distinguish them from
source code if they were located in their own subdirectory, maybe
'geode-docs' for example. This would be helpful during the comment period,
as well as later when the docs have been accepted as part of the main repo.
- To what extent is the directory structure dictated by Apache precedent?
- Can the locations be changed during the comment period?
- If not, can the locations be changed after the comment period, before the
branch is merged into the main repo?

Thanks,
Dave Barnes

Re: jvsd

[Dave Barnes]

Good observations, John.
A clarification: JVSD is Geode-only. The corresponding GemFire tool, VSD,
enjoys a more 'mainstream' status, at least for now, so it still appears in
the GF user guide.


On Fri, Sep 23, 2016 at 9:34 AM, John Blum <jb...@pivotal.io> wrote:

> +1
>
> Even a bit of documentation (which seems scattered about... in the
> specification, on VMW sites/properties, etc) would go a long way in helping
> users realize the benefit of the tool and provide feedback, maybe even
> contribute some PRs.  Having metrics on GemFire in realtime is hugely
> invaluable (even just explaining all the metrics and what they mean, how
> they are visualized should be sufficient).
>
> On Fri, Sep 23, 2016 at 9:32 AM, Dave Barnes <dbar...@pivotal.io> wrote:
>
> > Here's a proposal based on what I've seen in this thread:
> > 1. We remove JVSD documentation from the user manual.
> > 2. We save what's been written so far (mostly just build instructions)
> as a
> > README on the feature branch.
> >
> > On Thu, Sep 22, 2016 at 7:40 PM, Anthony Baker <aba...@pivotal.io>
> wrote:
> >
> > > Corporate org structures don’t get a voice on ASF mailing lists, only
> > > community participants :-)
> > >
> > > Anthony
> > >
> > >
> > > Begin forwarded message:
> > >
> > > *From: *Dave Barnes <dbar...@pivotal.io>
> > > *Subject: **Re: jvsd*
> > > *Date: *September 22, 2016 at 4:37:19 PM PDT
> > > *To: *dev@geode.incubator.apache.org
> > > *Reply-To: *dev@geode.incubator.apache.org
> > >
> > > Silence = "Docs group gets to pick"
> > >
> > >
> > >
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Re: jvsd

[Dave Barnes]

Here's a proposal based on what I've seen in this thread:
1. We remove JVSD documentation from the user manual.
2. We save what's been written so far (mostly just build instructions) as a
README on the feature branch.

On Thu, Sep 22, 2016 at 7:40 PM, Anthony Baker <aba...@pivotal.io> wrote:

> Corporate org structures don’t get a voice on ASF mailing lists, only
> community participants :-)
>
> Anthony
>
>
> Begin forwarded message:
>
> *From: *Dave Barnes <dbar...@pivotal.io>
> *Subject: **Re: jvsd*
> *Date: *September 22, 2016 at 4:37:19 PM PDT
> *To: *dev@geode.incubator.apache.org
> *Reply-To: *dev@geode.incubator.apache.org
>
> Silence = "Docs group gets to pick"
>
>
>

Re: Hibernate module and Geode 1.0 ?

[Dave Barnes]

Note: Doc situation is similar to that of JVSD, except there are more docs
for Hibernate.

On Thu, Sep 22, 2016 at 3:55 PM, William Markito 
wrote:

> If moving to a feature branch is a better approach, I'm fine as well..
>
> On Thu, Sep 22, 2016 at 3:45 PM, Udo Kohlmeyer 
> wrote:
>
> > Correct. Put it on a feature branch awaiting contributions.
> >
> >
> >
> > On 23/09/2016 8:41 AM, Anthony Baker wrote:
> >
> >> By remove, do you mean “put it on a feature branch awaiting
> >> contributions?”
> >>
> >> hibernate-3.5.5 was released in 2010 and has undergone significant
> >> changes since then.  Seems reasonable to put this feature on hold until
> can
> >> be brought current.
> >>
> >> Anthony
> >>
> >> On Sep 22, 2016, at 3:31 PM, Udo Kohlmeyer 
> wrote:
> >>>
> >>> +1 to removing until updated to newer version
> >>>
> >>> Do we know if anyone in the big-bad world is using it?
> >>>
> >>> --Udo
> >>>
> >>>
> >>> On 23/09/2016 8:15 AM, William Markito wrote:
> >>>
>  Folks,
> 
>  We're still building the Hibernate cache module [1] but it's
> compatible
>  only with a very old version (3.5) and given that the API has
> completely
>  changed and unless someone in the community wants to help getting this
>  module up-to-date with at least Hibernate 5.x I'd like propose to
> remove
>  the module from 1.0 / develop until we can work on updating that
> module.
> 
>  Given that it's already a separate module it shouldn't be that hard to
>  be
>  removed.
> 
>  Thoughts ?
> 
>  [1]
>  http://geode.docs.pivotal.io/docs/tools_modules/hibernate_ca
>  che/chapter_overview.html
> 
> 
> >
>
>
> --
>
> ~/William
>

Re: jvsd

[Dave Barnes]

Process for handling Experimental docs is still being hammered out. Common
element among working scenarios is isolation from the body of the User
Guide proper, so I'll remove the JVSD component from the User Guide's Tools
and Modules section.
Could go on the Wiki, could go in an appendix. We'll see what emerges.
Any favorites among the readers of this thread?
Silence = "Docs group gets to pick"

On Thu, Sep 22, 2016 at 3:37 PM, John Blum <jb...@pivotal.io> wrote:

> Truthfully, I don't think this is any different than API features that have
> been annotated with "@Experimental" (e.g. LucenceService
> <http://geode.incubator.apache.org/releases/latest/
> javadoc/com/gemstone/gemfire/cache/lucene/LuceneService.html>).
> I.e. nothing is going to stop a user from trying to use a
> feature/function/tool and searching for relevant information on how to use
> it if they know it exists, either explicitly or implicitly.
>
> In fact, I would think it is advantageous if they know it does exist, even
> prior to an official release, so that feedback can be gathered.
>
> If it is not to be part of the "official" User Guide, perhaps a Wiki page
> (other than the specification
> <https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=61309918=contextnavpagetreemode>
> [1])
> or better yet, a GitHub README page along with the source code if users are
> given access to build and use the tool themselves.
>
> If part of the "official" User Guide (under tools), then perhaps a
> "Experimental" label.
>
> Food for thought.
>
> -John
>
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=61309918=contextnavpagetreemode
>
>
> On Thu, Sep 22, 2016 at 3:19 PM, Anthony Baker <aba...@pivotal.io> wrote:
>
> > I think that providing documentation for jvsd before it is included in
> the
> > source and binary release distributions will only confuse users.  +1 for
> > removing.
> >
> > Anthony
> >
> > > On Sep 22, 2016, at 2:39 PM, Dave Barnes <dbar...@pivotal.io> wrote:
> > >
> > > JVSD has appeared in the Geode user manual since M2. See
> > > http://geode.docs.pivotal.io/docs/tools_modules/jvsd.html.
> > > Kirk, are you recommending that we remove this?
> > >
> > > On Thu, Sep 22, 2016 at 10:57 AM, Kirk Lund <kl...@apache.org> wrote:
> > >
> > >> I would recommend not mentioning jVSD at all in the Geode 1.0 docs.
> > Right
> > >> now it's just a Jira ticket and feature branch. I think the docs
> should
> > >> only cover what's in Geode 1.0.
> > >>
> > >> If there's some doc or wiki page about proposed future features or
> > features
> > >> currently looking for contributors/developers, then that would
> probably
> > be
> > >> an appropriate place to mention jVSD.
> > >>
> > >> Thanks,
> > >> Kirk
> > >>
> > >> On Thursday, September 22, 2016, Joey McAllister <
> > jmcallis...@pivotal.io>
> > >> wrote:
> > >>
> > >>> Bumping this. Any thoughts?
> > >>>
> > >>> On Tue, Sep 20, 2016 at 10:50 AM Dave Barnes <dbar...@pivotal.io
> > >>> <javascript:;>> wrote:
> > >>>
> > >>>> To what degree should jVSD be mentioned in the docs? The current
> > >> writeup
> > >>> is
> > >>>> essentially "go get it if you want it, but be warned that it's not
> > >> fully
> > >>>> baked and we don't support it".
> > >>>> Would that still be the appropriate jVSD policy for 1.0.0?
> > >>>>
> > >>>> On Tue, Sep 20, 2016 at 10:42 AM, Dan Smith <dsm...@pivotal.io
> > >>> <javascript:;>> wrote:
> > >>>>
> > >>>>> I don't think we should try to include jVSD in 1.0.0 at this point,
> > >>>> because
> > >>>>> it introduces dependencies that might make the 1.0.0 release more
> > >>>>> complicated such as the MultiAxisChartFX dependency. But I think
> the
> > >>>> should
> > >>>>> try to get it to develop sooner rather than later to make it easier
> > >> for
> > >>>>> people to get jVSD and play with it.
> > >>>>>
> > >>>>> -Dan
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Re: jvsd

[Dave Barnes]

To what degree should jVSD be mentioned in the docs? The current writeup is
essentially "go get it if you want it, but be warned that it's not fully
baked and we don't support it".
Would that still be the appropriate jVSD policy for 1.0.0?

On Tue, Sep 20, 2016 at 10:42 AM, Dan Smith  wrote:

> I don't think we should try to include jVSD in 1.0.0 at this point, because
> it introduces dependencies that might make the 1.0.0 release more
> complicated such as the MultiAxisChartFX dependency. But I think the should
> try to get it to develop sooner rather than later to make it easier for
> people to get jVSD and play with it.
>
> -Dan
>

Review Request 51764: GEODE-1880 DistributedSystem.java: typo repair in javadocs

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51764/
---

Review request for geode, Joey McAllister and Karen Miller.


Repository: geode


Description
---

GEODE-1880 DistributedSystem.java: typo repair in javadocs


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystem.java
 cb6851f4382950ffe3b9ba3a4c04a1288acb14be 

Diff: https://reviews.apache.org/r/51764/diff/


Testing
---


Thanks,

Dave Barnes

Re: Geode M3 docs: Review opportunity

[Dave Barnes]

This version of the Geode User Manual has been posted to the public site:
http://geode.docs.pivotal.io/



On Wed, Aug 10, 2016 at 1:15 PM, William Markito <wmark...@pivotal.io>
wrote:

> LGTM.  +1
>
> Thanks Dave!
>
> On Mon, Aug 8, 2016 at 11:40 AM, Dave Barnes <dbar...@pivotal.io> wrote:
>
> > I've posted the Geode User docs for the upcoming M3 release here:
> >
> > http://geode-review.cfapps.io/
> >
> > Please have a look at the section(s) describing the features you've
> > implemented and send me any suggestions or corrections.
> > Deadline is Code Release or this Friday, Aug 12, whichever comes first.
> > Thanks,
> > -Dave
> >
>
>
>
> --
>
> ~/William
>

Re: Experimental features for 1.0

[Dave Barnes]

JVSD is not fully-featured, yet. Does it belong on the list?

> On Aug 10, 2016, at 6:26 PM, Kirk Lund  wrote:
> 
> +1 for Jira tickets with "experimental" label
> 
> Also, don't forget we have the @Experimental annotation defined in
> geode-common that should be applied to any experimental user APIs before
> final 1.0.0 release.
> 
> -Kirk
> 
>> On Wednesday, August 10, 2016, William Markito  wrote:
>> 
>> As we move forward to 1.0 I'd like to propose creating JIRAS with the
>> "experimental" label to capture everything we have that is classified as
>> such.
>> 
>> This would help users and projects consume Geode to consider those
>> features properly and decide to add support (or not) to them as well.
>> 
>> AFAIK this is the current list:
>> 
>> Redis Adapter
>> Spark Connector
>> OQL Aggregates
>> Lucene integration
>> Auto Rebalancer
>> 
>> Is there anything else ? Are any of these not considered experimental
>> anymore ?
>> 
>> If by the time we get to 1.0 they're complete we'd remove be label
>> obviously.
>> 
>> Thoughts ?
>> 
>> 
>> 
>> 
>> 

Geode M3 docs: Review opportunity

[Dave Barnes]

I've posted the Geode User docs for the upcoming M3 release here:

http://geode-review.cfapps.io/

Please have a look at the section(s) describing the features you've
implemented and send me any suggestions or corrections.
Deadline is Code Release or this Friday, Aug 12, whichever comes first.
Thanks,
-Dave

Re: Review Request 50811: GEODE-1241: Fixing the misspelt words in the geode-wan

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50811/#review144814
---



I found a few possible problems, but need a knowledgable developer to verify.

1. 
geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderImpl.java:

The tool changed "we don't **neet**" to "we don't **meet**". Probably 
should have changed to "we don't **need**" - please verify.

2. 
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/misc/CommonParallelGatewaySenderDUnitTest.java:

The change is "2>**Comman** parallel sender for different non colocated 
regions is not supported" to "2>**Common**...". Should this be "**Command**"? 
Please verify.[3 occurrences in the file]

3. 
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/misc/ReplicatedRegion_ParallelWANPersistenceDUnitTest.java:

Same **Comman** to **Common** as above, maybe should be **Command**. 4 
occurrences. Please verify.

4. 
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANStatsDUnitTest.java

public void testReplicatedSerialPropagation**UNPorcessedEvents()** was 
changed to public void testReplicatedSerialPropagation**UNProcessedEvents()**. 
Any chance this should have been **UnprocessedEvents()**? Please verify.

- Dave Barnes


On Aug. 4, 2016, 5:25 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50811/
> ---
> 
> (Updated Aug. 4, 2016, 5:25 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Dave Barnes, 
> Jason Huynh, Kirk Lund, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is related to the ticket filed by Kirk which mentioned a list of classes 
> and methods with misspelt words. Using the inspect tool in the IntelliJ IDEA, 
> I was able to a get a list of 231 spelling mistake and missed  camelCasing in 
> the geode-wan module. These are fixed in this patch.  Remaining modules will 
> be fixed in the future. NOTE: this patch doesn't fix meaningless variable 
> names like 'serv' or 'cus'. They will be fixed in the future.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/i18n/LocalizedStrings.java
>  2254a89 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/cache/client/internal/GatewaySenderBatchOp.java
>  ef5f816 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/cache/client/internal/locator/wan/LocatorDiscovery.java
>  bbaed1d 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/cache/client/internal/locator/wan/LocatorHelper.java
>  1f36b12 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/cache/client/internal/locator/wan/WanLocatorDiscovererImpl.java
>  cde1e15 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
>  faef65c 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderFactoryImpl.java
>  3e3244e 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderImpl.java
>  8f5b728 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/serial/RemoteSerialGatewaySenderEventProcessor.java
>  56f3b39 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/cache/CacheXml70GatewayDUnitTest.java
>  3dfbfe9 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/cache/CacheXml80GatewayDUnitTest.java
>  f229e0f 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/UpdateVersionDUnitTest.java
>  f076aef 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/CacheClientNotifierDUnitTest.java
>  24b3a40 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  79648e1 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderDUnitTest.java
>  ee9edf8 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java
>  106ab4b 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentWANPropagation_1_DUnitTest.java
>  PRE-CREATION 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentWANPropagation_2_DUnitTest.java
>  PRE-CREATION 
>   
> geode-wan/src/te

Re: Geode website tagged with minor Apache branding issue in audit

[Dave Barnes]

My first question is what's the goal - is there another ASF site that would
serve as an example to follow?
Our current Apache info is a menu item at the bottom of the page. From the
report, I gather that the auditor wants to see the logos and disclaimer
"above the fold". More prominent logos can be easily done, once we agree on
where they should be located.
Can I safely assume that a [link to the disclaimer] is sufficient?
The branding guide (http://incubator.apache.org/guides/branding.html) lacks
specifics.

On Thu, Jun 30, 2016 at 9:20 PM, Greg Chase  wrote:

> Dear Geode community,
> I see the Apache Geode website got tagged with a minor branding concern in
> a recent audit of incubating projects.
>
> See the wiki entry here:
> https://wiki.apache.org/incubator/BrandingAuditJune2016
>
> See start of the thread in gene...@incubator.apache.org here:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201606.mbox/%3CCAOqetn-c49sfXSMck8hx%3DjGZQEw6paEmbdtMg32meLkHKcTPnQ%40mail.gmail.com%3E
>
> Basically the Apache & Apache incubator logos, and the incubator disclaimer
> are not prominent enough, but at least they are present.
>
> Next time we look at a website update, we might see how we can make these
> more obvious.
>
> Suggestions are welcome on this thread.
>
> -Greg
>

Re: update website for WAN, CQ and native client

[Dave Barnes]

I agree with Greg that we shouldn't use the Redis logo.

On Fri, Jun 17, 2016 at 11:56 AM, Gregory Chase  wrote:

> On Fri, Jun 17, 2016 at 11:49 AM, Anilkumar Gingade 
> wrote:
>
> > John is Right...WAN is more than just a replication of data...In order to
> > highlight and meaningful we have described this as Muti Site (WAN)
> Topology
> > in GemFire docs...
> >
> > -Anil.
> >
>
> Boom!  "Multi-site' or "Multi-Cluster"
>
>
> --
> Greg Chase
>
> Global Head, Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Re: update website for WAN, CQ and native client

[Dave Barnes]

I want to say "like a WAN". Just subjective, what do you think?

On Thu, Jun 16, 2016 at 11:44 PM, Joey McAllister 
wrote:

> +1
>
> Looks great, Swapnil.
> On Thu, Jun 16, 2016 at 11:16 PM Swapnil Bawaskar 
> wrote:
>
> > Thanks for the feedback. Here is take 2: http://i.imgur.com/gmsHomO.png
> >
> > On Thu, Jun 16, 2016 at 10:59 AM, John Blum  wrote:
> >
> > > @Swap-
> > >
> > > Perhaps we should mention Geode also supports *Redis* and *Memcached*
> > > clients (through the respective protocols) as well, though we do not
> > > develop dedicated clients for either.
> > >
> > > Thoughts on how to best represent that?
> > >
> > > -John
> > >
> > >
> > > On Thu, Jun 16, 2016 at 5:51 AM, Jacob Barrett 
> > > wrote:
> > >
> > > > -1
> > > >
> > > > I would not mention native clients yet since they aren't anywhere
> near
> > a
> > > > state to be built and used.
> > > > On Thu, Jun 16, 2016 at 5:32 AM yang theseus 
> > > > wrote:
> > > >
> > > > > +1 great!
> > > > >
> > > > > 2016-06-16 15:14 GMT+08:00 Gregory Chase :
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Wed, Jun 15, 2016 at 11:27 PM, Swapnil Bawaskar <
> > > > sbawas...@pivotal.io
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > WAN and CQ were the major features of M2 release[1]. Also,
> Native
> > > > > client
> > > > > > > has been donated to apache [2]. Considering these new
> features, I
> > > > would
> > > > > > > like to update the geode website [3] <
> > > > > http://geode.incubator.apache.org/
> > > > > > >
> > > > > > > and add these new features as captured in this image [4]
> > > > > > > .
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Swapnil.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334709
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201605.mbox/%3CCAEwge-ENhF4s_k5Y%3Dh9-mNFANb777j8bNDe4U9jahPYim61pfg%40mail.gmail.com%3E
> > > > > > > [3] http://geode.incubator.apache.org/
> > > > > > > [4] http://i.imgur.com/3Jad68K.png
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Greg Chase
> > > > > >
> > > > > > Global Head, Big Data Communities
> > > > > > http://www.pivotal.io/big-data
> > > > > >
> > > > > > Pivotal Software
> > > > > > http://www.pivotal.io/
> > > > > >
> > > > > > 650-215-0477
> > > > > > @GregChase
> > > > > > Blog: http://geekmarketing.biz/
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -John
> > > 503-504-8657
> > > john.blum10101 (skype)
> > >
> >
>

Re: New committer and PPMC Member: Nabarun Nag

[Dave Barnes]

Welcome, Nabarun!

On Tue, Jun 14, 2016 at 3:07 PM, Dan Smith 
wrote:

> Please welcome the newest committer to the apache Geode project - Nabarun
> Nag!
>
> We appreciate all the work he has already contributed thus far and are
> looking forward to continued involvement with Geode as a committer and PPMC
> member.
>
> -Dan
>

Re: new wiki content

[Dave Barnes]

Good stuff, Karen. Complements the material in App Dev -> troubleshooting
without duplicating it. A nice addition to the wiki!

On Tue, Jun 7, 2016 at 1:19 PM, Karen Miller  wrote:

> Feedback and suggestions welcomed on a newly added Apache Geode
> (incubating) wiki subject at
>   https://cwiki.apache.org/confluence/display/GEODE/Index
> The content is under the new category of Handling User Issues and Design.
>
> The first subject addressed is that of heap memory space and what happens
> when a Geode
> member exceeds threshold values in its heap allocation.
>
> This content targets users designing with Geode, aiming to expand into
> that elusive target of best practices in design.
>
>
>
>

Re: Review Request 48175: GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48175/#review136006
---


Ship it!




I believe that the code is correct - it appears to fix the six instances listed 
in the ticket (JIRA-1408).

The 6 targets were:
 - entry-idle-time-expiration-action
 - entry-time-to-live-expiration-action
 - region-idle-time-expiration-action
 - region-time-to-live-expiration-action
 - cache-loader
 - cache-writer

But for the record, the descriptive review text labeled "Here is the new help 
output" mistakenly shows a change for cache-listener, which in fact was made 
(correctly) in the code to cache-writer.

- Dave Barnes


On June 2, 2016, 5:05 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48175/
> ---
> 
> (Updated June 2, 2016, 5:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Karen Miller, Kevin Duling, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  d27786f72f039448b23af97408061cdd87295bfc 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
>  3c0d388d5af2c72864032d9ff0b469ddb4ff4393 
> 
> Diff: https://reviews.apache.org/r/48175/diff/
> 
> 
> Testing
> ---
> 
> Here is the new help output:
> 
> NAME
> alter region
> IS AVAILABLE
> false
> SYNOPSIS
> Alter a region with the given path and configuration.
> SYNTAX
> alter region --name=value [--group=value(,value)*] 
> [--entry-idle-time-expiration(=value)?] 
> [--entry-idle-time-expiration-action(=value)?] 
> [--entry-time-to-live-expiration(=value)?] 
> [--entry-time-to-live-expiration-action(=value)?]
> [--region-idle-time-expiration(=value)?] 
> [--region-idle-time-expiration-action(=value)?] 
> [--region-time-to-live-expiration(=value)?] 
> [--region-time-to-live-expiration-action(=value)?] 
> [--cache-listener=value(,value)*] [--cache-loader=value]
> [--cache-writer=value] [--async-event-queue-id=value(,value)*] 
> [--gateway-sender-id=value(,value)*] [--enable-cloning(=value)?] 
> [--eviction-max(=value)?]
> PARAMETERS
> name
> Name/Path of the region to be altered.
> Required: true
> group
> Group(s) of members on which the region will be altered.
> Required: false
> entry-idle-time-expiration
> How long the region's entries can remain in the cache without being 
> accessed. The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> entry-idle-time-expiration-action
> Action to be taken on an entry that has exceeded the idle expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> entry-time-to-live-expiration
> How long the region's entries can remain in the cache without being 
> accessed or updated. The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> entry-time-to-live-expiration-action
> Action to be taken on an entry that has exceeded the TTL expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> region-idle-time-expiration
> How long the region can remain in the cache without being accessed. 
> The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> region-idle-time-expiration-action
> Action to be taken on a region that has exceeded the idle expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> region-time-to-live-expiration
> How long the region can remain in the cache without being accessed or 
> update

Re: Review Request 48148: GEODE-1179: Remove references to vsd

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48148/#review135866
---


Ship it!




- Dave Barnes


On June 1, 2016, 6:49 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48148/
> ---
> 
> (Updated June 1, 2016, 6:49 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Also removed lingering references to DataBrowser
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/Launcher.java
>  5d57db6c31585cf63b4fdab4ff328fb9c9c2d94e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java
>  eca3e65ff7ffe27a9d1b4c954ea7b6cf64e7c5d6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
>  241c9e217efb05ad1cb8bb5458cb86121e7848f9 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/TestCommand.java
>  2ddc6eee691b7305a0618f9a40e03a39526bc7b5 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
>  74db3930d216fffa57342d215a520b935980d5e1 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-online.properties
>  57f8f37c5df5840895d8d3374502884f95ed9829 
> 
> Diff: https://reviews.apache.org/r/48148/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 48150: GEODE-1185: typo in gfsh help on alter disk-store

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48150/#review135865
---


Ship it!




- Dave Barnes


On June 1, 2016, 7:05 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48150/
> ---
> 
> (Updated June 1, 2016, 7:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1185: typo in gfsh help on alter disk-store
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
>  241c9e217efb05ad1cb8bb5458cb86121e7848f9 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
>  74db3930d216fffa57342d215a520b935980d5e1 
> 
> Diff: https://reviews.apache.org/r/48150/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: What will it take to release geode 1.0?

[Dave Barnes]

Ahh, my misunderstanding...I thought '1.0' was synonymous with
'post-incubation'.
We're hoping to convert our docs from DITA to Markdown before contributing
to ASF, still in the early stages of that conversion.
We'll keep plugging away and keep our eye on the software releases.

On Fri, Apr 29, 2016 at 2:58 PM, Dan Smith <dsm...@pivotal.io> wrote:

> I'm not sure if the docs are a prerequisite for graduation. I don't think
> there are specific requirements about the level of documentation for
> graduation, just about community involvement - which docs could help
> encourage :)
>
> In any case we don't need to graduate or even be graduation ready to
> release 1.0. The version number 1.0 has no special meaning to the ASF as
> far as I can tell. But I think having regular releases and having an
> official non-milestone release will help us grow the community.
>
> This page has some information on what's required for graduation:
>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>
> -Dan
>
>
> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <dbar...@pivotal.io> wrote:
>
> > We plan at some point to donate the docs so they'll be incorporated into
> > the repo. Is this a prerequisite to graduating from incubation?
> >
> > On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> > > The package renaming would most likely break some backwards
> compatibility
> > > between 1.0 and 2.0. I'd prefer to see the packages get renamed before
> > 1.0
> > > so we can change the packages of Message classes, etc in the same
> release
> > > that introduces the new JGroups.
> > >
> > > The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > > joptsimple.*, org.json.* (would we change all four or just the
> > > gemstone/vmware packages?).
> > >
> > > I'm probably biting off more than I should, but I'd be willing head up
> > the
> > > package renaming effort.
> > >
> > > I think maintaining backwards compatibility (rolling upgrades included)
> > for
> > > releases following Geode 1.0 is a definite requirement. I'd like to see
> > the
> > > other discussion thread about defining the Geode protocol(s) converge
> > with
> > > this thread. Officially defining the communication protocols (cluster,
> > > client/server, etc) would ideally happen in conjunction with 1.0 so
> that
> > > it's concrete and less ambiguous for 2.0 and later releases.
> > >
> > > -Kirk
> > >
> > >
> > > On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <dsm...@pivotal.io> wrote:
> > >
> > > > We've been releasing milestones of 1.0, but at some point we actually
> > > have
> > > > to release a real geode 1.0 :)
> > > >
> > > > What is keeping us from releasing geode 1.0 at this point? Just the
> > > issues
> > > > currently marked with Fix Version M3? I think we should nail down the
> > > scope
> > > > of 1.0 and track our progress to the 1.0 release.
> > > >
> > > > From the apache process perspective, I don't think 1.0 is any
> different
> > > > from the milestone releases we've done so far. The only difference
> with
> > > 1.0
> > > > is what it means to the geode community.
> > > >
> > > > Gemfire maintained backwards compatibility with previous releases for
> > > > persistent files, client/server, WAN, and P2P messaging. I think once
> > we
> > > > release 1.0 we should provide that same guarantee that the next geode
> > > > release will be backwards compatible with 1.0.
> > > >
> > > > We do still have the package renaming (GEODE-37) on the horizon. My
> > > > suggestion is that in the interests of getting 1.0 out the door, at
> > this
> > > > point we should just release geode 1.0 with the old packages and
> rename
> > > > packages in geode 2.0.
> > > >
> > > > Thoughts?
> > > >
> > > > -Dan
> > > >
> > >
> >
>

Re: What will it take to release geode 1.0?

[Dave Barnes]

We plan at some point to donate the docs so they'll be incorporated into
the repo. Is this a prerequisite to graduating from incubation?

On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund  wrote:

> The package renaming would most likely break some backwards compatibility
> between 1.0 and 2.0. I'd prefer to see the packages get renamed before 1.0
> so we can change the packages of Message classes, etc in the same release
> that introduces the new JGroups.
>
> The packages are currently a mess of com.gemstone.*, com.vmware.*,
> joptsimple.*, org.json.* (would we change all four or just the
> gemstone/vmware packages?).
>
> I'm probably biting off more than I should, but I'd be willing head up the
> package renaming effort.
>
> I think maintaining backwards compatibility (rolling upgrades included) for
> releases following Geode 1.0 is a definite requirement. I'd like to see the
> other discussion thread about defining the Geode protocol(s) converge with
> this thread. Officially defining the communication protocols (cluster,
> client/server, etc) would ideally happen in conjunction with 1.0 so that
> it's concrete and less ambiguous for 2.0 and later releases.
>
> -Kirk
>
>
> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith  wrote:
>
> > We've been releasing milestones of 1.0, but at some point we actually
> have
> > to release a real geode 1.0 :)
> >
> > What is keeping us from releasing geode 1.0 at this point? Just the
> issues
> > currently marked with Fix Version M3? I think we should nail down the
> scope
> > of 1.0 and track our progress to the 1.0 release.
> >
> > From the apache process perspective, I don't think 1.0 is any different
> > from the milestone releases we've done so far. The only difference with
> 1.0
> > is what it means to the geode community.
> >
> > Gemfire maintained backwards compatibility with previous releases for
> > persistent files, client/server, WAN, and P2P messaging. I think once we
> > release 1.0 we should provide that same guarantee that the next geode
> > release will be backwards compatible with 1.0.
> >
> > We do still have the package renaming (GEODE-37) on the horizon. My
> > suggestion is that in the interests of getting 1.0 out the door, at this
> > point we should just release geode 1.0 with the old packages and rename
> > packages in geode 2.0.
> >
> > Thoughts?
> >
> > -Dan
> >
>

Review Request 45971: GEODE-1204 modified conditionals and opacity to make logo visible on Releases page.

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45971/
---

Review request for geode.


Repository: geode


Description
---

GEODE-1204 modified conditionals and opacity to make logo visible on Releases 
page.


Diffs
-

  geode-site/website/Rules 5369385483369d0fee30786733f8692959bcbf4a 
  geode-site/website/layouts/default.html 
2e3e2cd61917eb75be982c4ca6edac110e435846 
  geode-site/website/layouts/header.html 
6edaec80653cf8b99065e7c559ee4b13c8041101 
  geode-site/website/layouts/releases.html PRE-CREATION 

Diff: https://reviews.apache.org/r/45971/diff/


Testing
---


Thanks,

Dave Barnes

Re: Review Request 45879: (GEODE-1186) Geode website: reinstate Google Analytics

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45879/
---

(Updated April 7, 2016, 6:43 p.m.)


Review request for geode, Anthony Baker, William Markito, and Sai Boorlagadda.


Changes
---

Per Google's recommendation, relocated Google analytics snippet from footer to 
header


Repository: geode


Description
---

(GEODE-1186) Geode website: reinstate Google Analytics


Diffs (updated)
-

  geode-site/website/layouts/footer.html 
3d31236a76a0182bf43d8ebfc12a8ad610db7cf3 
  geode-site/website/layouts/header.html 
5d89d7184115c8d41133bd8840d9d142b793a9da 

Diff: https://reviews.apache.org/r/45879/diff/


Testing
---


Thanks,

Dave Barnes

Review Request 45879: (GEODE-1186) Geode website: reinstate Google Analytics

[Dave Barnes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45879/
---

Review request for geode, Anthony Baker, William Markito, and Sai Boorlagadda.


Repository: geode


Description
---

(GEODE-1186) Geode website: reinstate Google Analytics


Diffs
-

  geode-site/website/layouts/footer.html 
3d31236a76a0182bf43d8ebfc12a8ad610db7cf3 

Diff: https://reviews.apache.org/r/45879/diff/


Testing
---


Thanks,

Dave Barnes

Need a boost in my JIRA privileges

[Dave Barnes]

I can create JIRA tickets and comment on them, but am unable to assign a
ticket (even to myself). Would someone be so kind as to enlarge my scope?
My Apache JIRA ID is 'dbarnes97'.
Thanks,
-Dave

Re: New Comitter & PPMC member: Sai Boorlagadda

[Dave Barnes]

Pull request #105 has been submitted to add Sai to the committer's list on
the website.

On Wed, Mar 2, 2016 at 10:06 AM, William Markito 
wrote:

> Please welcome *Sai Boorlagadda* as a new committer to the Apache Geode
> project!
> We appreciate all the patches he has already contributed and are
> hoping to see many more future contributions.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity. Being a PMC member enables assistance with the management and
> to guide the direction of the project.
>
> Thanks,
> ~/William
>
> --
> ~/William
>

Re: Conributors.md

[Dave Barnes]

+1 to providing a more obvious path to the "how to contribute" info. This
thread suggests two possibilities:

   - add a CONTRIBUTING.md (or CONTRIBUTORS.md) file to the sources, or
   - Add a link to the cwiki page (
   https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute).

I like the second, the cwiki link, because we can update the information in
a single place without having to check in new sources.
Anyone else have a preference?


On Tue, Mar 1, 2016 at 8:19 AM, Nitin Lamba  wrote:

> Hi Dor,
>
> From the e-mail subject, is this question about capturing the list of
> contributors on the Geode project? The website has a list of committers on
> the community page [1]; perhaps a link to contribution guidelines (wiki)
> can be created from there.
>
> Nitin
> [1] http://geode.incubator.apache.org/community/
> 
> From: Anthony Baker 
> Sent: Thursday, February 25, 2016 9:42 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Conributors.md
>
> Hi Dor,
>
> We have some information on that subject in the wiki:
> https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute
>
> What would like to see added to a ‘CONTRIBUTING.md’ file?
>
> Anthony
>
> > On Feb 24, 2016, at 10:28 AM, Dor Ben Dov 
> wrote:
> >
> > Hi ,
> >
> >
> > Any possible way that you will add the contributing.md file to the root
> folder ?
> >
> >
> > Regards,
> > Dor Ben Dov
> >
> > This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Dave Barnes]

Based on some off-line discussions, as well as this thread, I'm buying into
the idea that all changes should follow the same rules. It's simpler that
way and the additional overhead of crafting a JIRA ticket is minimal,
really. [I'm assuming we won't run out of JIRA numbers anytime soon...]


On Mon, Feb 29, 2016 at 3:20 PM, Jens Deppe <jde...@pivotal.io> wrote:

> For things like 'doc typos' we could consider a Jira that remains open for
> a specific release or period of development and then gets closed at the end
> of that cycle.
>
> On Mon, Feb 29, 2016 at 1:55 PM, Kenneth Howe <kh...@pivotal.io> wrote:
>
> > +1 to Jake’s comment
> >
> > The number of “special cases” we’re talking about is pretty small
> compared
> > to the overall number commits. Even for doc typos it’s not a problem to
> > submit a JIRA when you see the problem. I’d be inclined to open one JIRA
> > for however many typos or minor textual errors I find on a read-through
> or
> > review of a doc.
> >
> > Ken
> >
> > > On Feb 29, 2016, at 1:42 PM, Dave Barnes <dbar...@pivotal.io> wrote:
> > >
> > > I withdraw the re-usable JIRA ticket suggestion - it was semi-facetious
> > > anyway.
> > >
> > > On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett <jbarr...@pivotal.io>
> > wrote:
> > >
> > >> +1
> > >>
> > >> All changes in the repo should have a ticket.
> > >>
> > >> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer <ukohlme...@pivotal.io
> >
> > >> wrote:
> > >>
> > >>> My opinion is that no work should be done without a JIRA. That way
> > there
> > >>> is a "documentation" on what the task is and you can measure the
> > outcome
> > >>> based on the JIRA.
> > >>>
> > >>> One might think that one could end up in a scenario where we'd end up
> > >>> creating JIRA's for the sake of creating JIRA's. But in the long run
> > >>> those "trivial" tasks become less frequent.
> > >>>
> > >>> I also thought that there was some unwritten rule that no changes
> shall
> > >>> be made directly in trunk/develop? ;)
> > >>>
> > >>>
> > >>>
> > >>> On 1/03/2016 6:05 am, Dan Smith wrote:
> > >>>> My opinion is that docs and minor changes to tests or build scripts
> > >> don't
> > >>>> need necessarily a JIRA. So I'm not sure we want to enforce this
> with
> > a
> > >>>> hook.
> > >>>>
> > >>>> That said, I definitely see commits in the log that look like
> product
> > >> bug
> > >>>> fixes, and I totally agree those should have ticket #s in the
> commit.
> > >>>>
> > >>>> Jason suggested something that I think might be a good idea - for
> > >> changes
> > >>>> that don't need a JIRA, maybe we can put some other tag in that
> spot.
> > >> For
> > >>>> example:
> > >>>>
> > >>>> DOCS: Update most occurrences of "Geode" to "Apache Geode".
> > >>>>
> > >>>> -Dan
> > >>>>
> > >>>> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> > >>> kareem.shab...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Is it by design that there are no client-side Git hooks to prevent
> > >> this
> > >>>>> sort of thing?
> > >>>>>
> > >>>>> --
> > >>>>> Kareem
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" <
> > kl...@pivotal.io
> > >>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Please remember to include the GEODE-xxx jira ticket # in your
> commit
> > >>>>> messages. I'm looking at git log on develop and I can't correlate
> > >>> several
> > >>>>> checkins with any jira tickets.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Kirk
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Dave Barnes]

I withdraw the re-usable JIRA ticket suggestion - it was semi-facetious
anyway.

On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett  wrote:

> +1
>
> All changes in the repo should have a ticket.
>
> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer 
> wrote:
>
> > My opinion is that no work should be done without a JIRA. That way there
> > is a "documentation" on what the task is and you can measure the outcome
> > based on the JIRA.
> >
> > One might think that one could end up in a scenario where we'd end up
> > creating JIRA's for the sake of creating JIRA's. But in the long run
> > those "trivial" tasks become less frequent.
> >
> > I also thought that there was some unwritten rule that no changes shall
> > be made directly in trunk/develop? ;)
> >
> >
> >
> > On 1/03/2016 6:05 am, Dan Smith wrote:
> > > My opinion is that docs and minor changes to tests or build scripts
> don't
> > > need necessarily a JIRA. So I'm not sure we want to enforce this with a
> > > hook.
> > >
> > > That said, I definitely see commits in the log that look like product
> bug
> > > fixes, and I totally agree those should have ticket #s in the commit.
> > >
> > > Jason suggested something that I think might be a good idea - for
> changes
> > > that don't need a JIRA, maybe we can put some other tag in that spot.
> For
> > > example:
> > >
> > > DOCS: Update most occurrences of "Geode" to "Apache Geode".
> > >
> > > -Dan
> > >
> > > On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> > kareem.shab...@gmail.com>
> > > wrote:
> > >
> > >> Is it by design that there are no client-side Git hooks to prevent
> this
> > >> sort of thing?
> > >>
> > >> --
> > >> Kareem
> > >>
> > >>
> > >>
> > >>
> > >> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund"  >
> > >> wrote:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Please remember to include the GEODE-xxx jira ticket # in your commit
> > >> messages. I'm looking at git log on develop and I can't correlate
> > several
> > >> checkins with any jira tickets.
> > >>
> > >> Thanks,
> > >> Kirk
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> >
>

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Dave Barnes]

Docs are an important part of the product and over time we plan to migrate
an increasing number of doc sources to the Apache Geode repo (or an allied
repo in the Apache universe). While the workflow for docs often resembles
that for code, there are also other case, such as typo repairs, that IMO
don't really merit individual JIRA tickets.
Would it be in harmony with the Apache Way to open a single JIRA ticket for
'doc typo repair,' keep it open, and re-use it over and over?
That would spare us from creating dozens of identical JIRA tickets that
differ only by number.


On Mon, Feb 29, 2016 at 11:39 AM, John Blum  wrote:

> On Spring projects, and in particular, Spring Data GemFire, we file JIRA
> tickets and categorize them as "tasks".  However, it not uncommon for a bug
> (fix)/enhancement/new-feature to have code/test/documentation changes all
> filed under a single JIRA.  For example...
>
> SGF-123 - Improve feature X...  // includes code changes/tests, maybe doc
> changes
> SGF-123 - Add additional test for use case/scenario...
> SGF-123 - Update documentation...
>
> etc
>
> -John
>
>
> On Mon, Feb 29, 2016 at 11:20 AM, Udo Kohlmeyer 
> wrote:
>
> > My opinion is that no work should be done without a JIRA. That way there
> > is a "documentation" on what the task is and you can measure the outcome
> > based on the JIRA.
> >
> > One might think that one could end up in a scenario where we'd end up
> > creating JIRA's for the sake of creating JIRA's. But in the long run
> those
> > "trivial" tasks become less frequent.
> >
> > I also thought that there was some unwritten rule that no changes shall
> be
> > made directly in trunk/develop? ;)
> >
> >
> >
> >
> > On 1/03/2016 6:05 am, Dan Smith wrote:
> >
> >> My opinion is that docs and minor changes to tests or build scripts
> don't
> >> need necessarily a JIRA. So I'm not sure we want to enforce this with a
> >> hook.
> >>
> >> That said, I definitely see commits in the log that look like product
> bug
> >> fixes, and I totally agree those should have ticket #s in the commit.
> >>
> >> Jason suggested something that I think might be a good idea - for
> changes
> >> that don't need a JIRA, maybe we can put some other tag in that spot.
> For
> >> example:
> >>
> >> DOCS: Update most occurrences of "Geode" to "Apache Geode".
> >>
> >> -Dan
> >>
> >> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> kareem.shab...@gmail.com
> >> >
> >> wrote:
> >>
> >> Is it by design that there are no client-side Git hooks to prevent this
> >>> sort of thing?
> >>>
> >>> --
> >>> Kareem
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" 
> >>> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Please remember to include the GEODE-xxx jira ticket # in your commit
> >>> messages. I'm looking at git log on develop and I can't correlate
> several
> >>> checkins with any jira tickets.
> >>>
> >>> Thanks,
> >>> Kirk
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Re: Build emails from Travis

[Dave Barnes]

Swapnil,
What is the significance of the Travis results? I see that the Travis job
failed on your PR #107, which was a doc change and therefore of particular
interest to me. There's nothing wrong with your change and it certainly
didn't introduce new code of any kind. What do we learn from Travis in this
case?
Will this be a typical result for all doc submissions?

On Thu, Feb 25, 2016 at 5:10 PM, Swapnil Bawaskar 
wrote:

> Do we want build emails from travis sent to the dev list?
>
> The default mechanism from the travis site
>  is as follows:
>
> By default, a build email is sent to the committer and the author, but only
> if they have access to the repository the commit was pushed to. This
> prevents forks active on Travis CI from notifying the upstream repository’s
> owners when they’re pushing any upstream changes to their fork. It also
> prevents build notifications from going to folks not registered on Travis
> CI.
>
> The email address is then determined based on the email address in the
> commit, but only if it matches one of the email addresses in our database.
> We synchronize all your email addresses from GitHub, solely for the purpose
> of build notifications.
>
>
> We can configure travis to send emails to the dev list when the state of
> the build changes (from passing to failing OR from failing to passing). No
> multiple emails on failing builds.
>
> Thanks!
> Swapnil.
>

Re: Proposal: Move Events to a non-Repo website

[Dave Barnes]

One month out, naught but crickets to be heard...
Guess we'll continue to update Events on the Community index page.
Please contribute! A dynamic Events listing conveys vitality, a stale one
conveys lethargy.
If you're not comfortable making an update, you can send your event to me
and I'll post it for you.

On Wed, Jan 27, 2016 at 10:22 AM, Dave Barnes <dbar...@pivotal.io> wrote:

> This question (does the external site idea play well with our community
> policies?) is an important one. My proposal comes from efficiency
> considerations - let's hear from the community: if consensus is that the
> proposal conflicts with policy, I'll certainly withdraw it.
> -Dave
>
> On Wed, Jan 27, 2016 at 9:57 AM, Anthony Baker <aba...@pivotal.io> wrote:
>
>> Is hosting the data on a site external to ASF infrastructure in accord
>> with our community policies?
>>
>> Anthony
>>
>> > On Jan 27, 2016, at 9:44 AM, Gregory Chase <gch...@pivotal.io> wrote:
>> >
>> > Pivotal Data Communities maintains this public calendar:
>> >
>> https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles
>> >
>> > However not sure we can sort out the Geode events.
>> >
>> > We can create an additional calendar to host on behalf of Apache Geode,
>> as
>> > much as I don't like double entry :)
>> >
>> > -Greg
>> >
>> > On Wed, Jan 27, 2016 at 9:40 AM, Dave Barnes <dbar...@pivotal.io>
>> wrote:
>> >
>> >> If we choose to proceed in this direction, we'll need a
>> >> community-accessible site that hosts a public Google calendar. Does
>> this
>> >> already exist, or do we need to create one?
>> >>
>> >>
>> >> On Tue, Jan 26, 2016 at 10:28 PM, William Markito <wmark...@pivotal.io
>> >
>> >> wrote:
>> >>
>> >>> The javascript integration you did looks really good to me...
>> Although
>> >> the
>> >>> Brazilian calendar might be too much given the number of holidays...
>> :P
>> >>>
>> >>> A separate website would be a bit confusing since it would not be
>> handled
>> >>> or managed within the project or by committers of the project, which
>> >> might
>> >>> be a similar problem for a google calendar but might more doable...
>> >>>
>> >>> About your second question the calendar widget would take of it once
>> the
>> >>> events pass.  For now, I'm not sure we need to be much concerned since
>> >> it's
>> >>> also good for people to see events that already happened so they can
>> find
>> >>> content...
>> >>>
>> >>> Just my 2 cents.
>> >>>
>> >>> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes <dbar...@pivotal.io>
>> wrote:
>> >>>
>> >>>> This was a proof-of-concept, but the redesign needs more thought. I
>> >>> think a
>> >>>> separate site will allow more flexibility in presentation and design.
>> >>>>
>> >>>> I'm not sure how much information most publicly-visible Google
>> >> calendars
>> >>>> provide, but this example's pretty slim. Doesn't begin to rival the
>> >>>> appearance or level of detail of the existing implementation.
>> >>>>
>> >>>> Those of us who care need to come up with a design. My first question
>> >> has
>> >>>> to do with existing resources:
>> >>>> Is there a website already in existence that could serve as a host
>> for
>> >>>> calendar postings from the community?
>> >>>>
>> >>>> Second question: In the meantime, how shall we handle updates to the
>> >>>> existing site? The Jan 31 event will go 'stale' in less than a week.
>> >>>>
>> >>>> On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io>
>> wrote:
>> >>>>
>> >>>>> +1 Good idea!
>> >>>>>
>> >>>>> -Dan
>> >>>>>
>> >>>>> On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase <g...@gregchase.com>
>> >>> wrote:
>> >>>>>
>> >>>>>> +1 for supporting Brazilian Holidays
>> >>>>>>
>> >>>>>> +1 for a cal

Pull Request Request

[Dave Barnes]

Would some conscientious committer be so kind as to accept PR #43? It's a
simple Javadoc update that's been in the queue since November.
Thanks in advance,
-Dave

Re: Proposal: Move Events to a non-Repo website

[Dave Barnes]

If we choose to proceed in this direction, we'll need a
community-accessible site that hosts a public Google calendar. Does this
already exist, or do we need to create one?


On Tue, Jan 26, 2016 at 10:28 PM, William Markito <wmark...@pivotal.io>
wrote:

> The javascript integration you did looks really good to me...  Although the
> Brazilian calendar might be too much given the number of holidays... :P
>
> A separate website would be a bit confusing since it would not be handled
> or managed within the project or by committers of the project, which might
> be a similar problem for a google calendar but might more doable...
>
> About your second question the calendar widget would take of it once the
> events pass.  For now, I'm not sure we need to be much concerned since it's
> also good for people to see events that already happened so they can find
> content...
>
> Just my 2 cents.
>
> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes <dbar...@pivotal.io> wrote:
>
> > This was a proof-of-concept, but the redesign needs more thought. I
> think a
> > separate site will allow more flexibility in presentation and design.
> >
> > I'm not sure how much information most publicly-visible Google calendars
> > provide, but this example's pretty slim. Doesn't begin to rival the
> > appearance or level of detail of the existing implementation.
> >
> > Those of us who care need to come up with a design. My first question has
> > to do with existing resources:
> > Is there a website already in existence that could serve as a host for
> > calendar postings from the community?
> >
> > Second question: In the meantime, how shall we handle updates to the
> > existing site? The Jan 31 event will go 'stale' in less than a week.
> >
> > On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io> wrote:
> >
> > > +1 Good idea!
> > >
> > > -Dan
> > >
> > > On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase <g...@gregchase.com>
> wrote:
> > >
> > > > +1 for supporting Brazilian Holidays
> > > >
> > > > +1 for a calendar service that makes it easier for the community to
> > > > contribute events.
> > > >
> > > > On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes <dbar...@pivotal.io>
> > wrote:
> > > >
> > > > > First pass, using the calendar of Brazilian Holidays - look just
> > below
> > > > the
> > > > > Pivotal events:
> > > > >
> > > > >
> http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> > > > >
> > > > > On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba <ni...@ampool.io>
> > wrote:
> > > > >
> > > > > > +1 for data-driven event calendar! William's suggested solution
> is
> > > > > > available as a jQuery plugin [1].
> > > > > >
> > > > > > Nitin
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
> > > > > >
> > > > > > 
> > > > > > From: William Markito <wmark...@pivotal.io>
> > > > > > Sent: Tuesday, January 26, 2016 12:00 AM
> > > > > > To: dev@geode.incubator.apache.org
> > > > > > Subject: Re: Proposal: Move Events to a non-Repo website
> > > > > >
> > > > > > Hi Dave,  I think it's a great idea!  In fact, I'd rather have it
> > > some
> > > > > how
> > > > > > (javascript ?) pull that data from a Google Calendar feed or
> > > something
> > > > > like
> > > > > > that to automate the updates.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes <dbar...@pivotal.io>
> > > > wrote:
> > > > > >
> > > > > > > RFF (Request for Feedback)
> > > > > > >
> > > > > > > Apache Geode website design suggestion: Replace the volatile
> > Events
> > > > > > section
> > > > > > > of the Geode website with a link to a community events site
> > that's
> > > > not
> > > > > > part
> > > > > > > of the Apache Geode source code repo. That way, the events can
> be
> > > > > updated
> > > > > > > quickly by community members without the delay, overhead, and
> > > > potential
> > > > > > > code corruption resulting from updating calendar items in the
> > code
> > > > > repo.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal: Move Events to a non-Repo website

[Dave Barnes]

This question (does the external site idea play well with our community
policies?) is an important one. My proposal comes from efficiency
considerations - let's hear from the community: if consensus is that the
proposal conflicts with policy, I'll certainly withdraw it.
-Dave

On Wed, Jan 27, 2016 at 9:57 AM, Anthony Baker <aba...@pivotal.io> wrote:

> Is hosting the data on a site external to ASF infrastructure in accord
> with our community policies?
>
> Anthony
>
> > On Jan 27, 2016, at 9:44 AM, Gregory Chase <gch...@pivotal.io> wrote:
> >
> > Pivotal Data Communities maintains this public calendar:
> >
> https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles
> >
> > However not sure we can sort out the Geode events.
> >
> > We can create an additional calendar to host on behalf of Apache Geode,
> as
> > much as I don't like double entry :)
> >
> > -Greg
> >
> > On Wed, Jan 27, 2016 at 9:40 AM, Dave Barnes <dbar...@pivotal.io> wrote:
> >
> >> If we choose to proceed in this direction, we'll need a
> >> community-accessible site that hosts a public Google calendar. Does this
> >> already exist, or do we need to create one?
> >>
> >>
> >> On Tue, Jan 26, 2016 at 10:28 PM, William Markito <wmark...@pivotal.io>
> >> wrote:
> >>
> >>> The javascript integration you did looks really good to me...  Although
> >> the
> >>> Brazilian calendar might be too much given the number of holidays... :P
> >>>
> >>> A separate website would be a bit confusing since it would not be
> handled
> >>> or managed within the project or by committers of the project, which
> >> might
> >>> be a similar problem for a google calendar but might more doable...
> >>>
> >>> About your second question the calendar widget would take of it once
> the
> >>> events pass.  For now, I'm not sure we need to be much concerned since
> >> it's
> >>> also good for people to see events that already happened so they can
> find
> >>> content...
> >>>
> >>> Just my 2 cents.
> >>>
> >>> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes <dbar...@pivotal.io>
> wrote:
> >>>
> >>>> This was a proof-of-concept, but the redesign needs more thought. I
> >>> think a
> >>>> separate site will allow more flexibility in presentation and design.
> >>>>
> >>>> I'm not sure how much information most publicly-visible Google
> >> calendars
> >>>> provide, but this example's pretty slim. Doesn't begin to rival the
> >>>> appearance or level of detail of the existing implementation.
> >>>>
> >>>> Those of us who care need to come up with a design. My first question
> >> has
> >>>> to do with existing resources:
> >>>> Is there a website already in existence that could serve as a host for
> >>>> calendar postings from the community?
> >>>>
> >>>> Second question: In the meantime, how shall we handle updates to the
> >>>> existing site? The Jan 31 event will go 'stale' in less than a week.
> >>>>
> >>>> On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io> wrote:
> >>>>
> >>>>> +1 Good idea!
> >>>>>
> >>>>> -Dan
> >>>>>
> >>>>> On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase <g...@gregchase.com>
> >>> wrote:
> >>>>>
> >>>>>> +1 for supporting Brazilian Holidays
> >>>>>>
> >>>>>> +1 for a calendar service that makes it easier for the community to
> >>>>>> contribute events.
> >>>>>>
> >>>>>> On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes <dbar...@pivotal.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> First pass, using the calendar of Brazilian Holidays - look just
> >>>> below
> >>>>>> the
> >>>>>>> Pivotal events:
> >>>>>>>
> >>>>>>>
> >>> http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> >>>>>>>
> >>>>>>> On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba <ni...@ampool.io>
>

Re: Proposal: Move Events to a non-Repo website

[Dave Barnes]

This was a proof-of-concept, but the redesign needs more thought. I think a
separate site will allow more flexibility in presentation and design.

I'm not sure how much information most publicly-visible Google calendars
provide, but this example's pretty slim. Doesn't begin to rival the
appearance or level of detail of the existing implementation.

Those of us who care need to come up with a design. My first question has
to do with existing resources:
Is there a website already in existence that could serve as a host for
calendar postings from the community?

Second question: In the meantime, how shall we handle updates to the
existing site? The Jan 31 event will go 'stale' in less than a week.

On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io> wrote:

> +1 Good idea!
>
> -Dan
>
> On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase <g...@gregchase.com> wrote:
>
> > +1 for supporting Brazilian Holidays
> >
> > +1 for a calendar service that makes it easier for the community to
> > contribute events.
> >
> > On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes <dbar...@pivotal.io> wrote:
> >
> > > First pass, using the calendar of Brazilian Holidays - look just below
> > the
> > > Pivotal events:
> > >
> > > http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> > >
> > > On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba <ni...@ampool.io> wrote:
> > >
> > > > +1 for data-driven event calendar! William's suggested solution is
> > > > available as a jQuery plugin [1].
> > > >
> > > > Nitin
> > > >
> > > > [1]
> > > >
> > >
> >
> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
> > > >
> > > > 
> > > > From: William Markito <wmark...@pivotal.io>
> > > > Sent: Tuesday, January 26, 2016 12:00 AM
> > > > To: dev@geode.incubator.apache.org
> > > > Subject: Re: Proposal: Move Events to a non-Repo website
> > > >
> > > > Hi Dave,  I think it's a great idea!  In fact, I'd rather have it
> some
> > > how
> > > > (javascript ?) pull that data from a Google Calendar feed or
> something
> > > like
> > > > that to automate the updates.
> > > >
> > > > +1
> > > >
> > > > On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes <dbar...@pivotal.io>
> > wrote:
> > > >
> > > > > RFF (Request for Feedback)
> > > > >
> > > > > Apache Geode website design suggestion: Replace the volatile Events
> > > > section
> > > > > of the Geode website with a link to a community events site that's
> > not
> > > > part
> > > > > of the Apache Geode source code repo. That way, the events can be
> > > updated
> > > > > quickly by community members without the delay, overhead, and
> > potential
> > > > > code corruption resulting from updating calendar items in the code
> > > repo.
> > > > >
> > > >
> > >
> >
>

Re: Obsolete Geode website - EOL?

[Dave Barnes]

Thanks!

On Mon, Jan 25, 2016 at 2:14 PM, Gregory Chase <gch...@pivotal.io> wrote:

> Its not the Apache project's responsibility as the "Project Geode" site is
> owned by Pivotal.  I'll get this to refer to the Apache project.
>
> -Greg
>
> On Mon, Jan 25, 2016 at 2:10 PM, Dave Barnes <dbar...@pivotal.io> wrote:
>
> > There's an out-of-date Geode site at
> > http://pivotalsoftware.github.io/geode-site/.
> > I'm not sure who owns this site, but I think it's time to end-of-life
> (EOL)
> > it - can it come down now?
> > Thanks!
> >
>
>
>
> --
> Greg Chase
>
> Director of Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Obsolete Geode website - EOL?

[Dave Barnes]

There's an out-of-date Geode site at
http://pivotalsoftware.github.io/geode-site/.
I'm not sure who owns this site, but I think it's time to end-of-life (EOL)
it - can it come down now?
Thanks!

Proposal: Move Events to a non-Repo website

[Dave Barnes]

RFF (Request for Feedback)

Apache Geode website design suggestion: Replace the volatile Events section
of the Geode website with a link to a community events site that's not part
of the Apache Geode source code repo. That way, the events can be updated
quickly by community members without the delay, overhead, and potential
code corruption resulting from updating calendar items in the code repo.

Re: Please Join us for the Inagural Geode Summit - early bird pricing through Jan 31st!

[Dave Barnes]

I can make this change, Greg.
Shall I keep the old postings from 2015 events or start fresh?

On Fri, Jan 22, 2016 at 12:08 PM, Gregory Chase  wrote:

> You are correct - needs to be updated.  Current website setup is a bit
> challenging for non-developers to update.
>
> On Fri, Jan 22, 2016 at 12:05 PM, Mark Bretl  wrote:
>
> > Hi Greg,
> >
> > I don't see this event on the community site,
> > http://geode.incubator.apache.org/community/#events, would you be able
> to
> > add it?
> >
> > --Mark
> >
> > On Thu, Jan 14, 2016 at 9:54 AM, Gregory Chase 
> wrote:
> >
> > > Pivotal Software is very excited to host this event for the Apache
> Geode
> > > (incubating) community:
> > >
> > > *Join Us!*
> > >
> > > *Pivotal, Palo Alto, CA|Wednesday, March 9, 2016*
> > >
> > > *Geode Summit Info Here: **http://geodesummit.com/
> > > *
> > >
> > > The inaugural Geode Summit is a full day conference to bring together
> the
> > > Apache Geode (incubating) community and GemFire users and developers.
> > > Attendees will engage with experts, core committers, and leading
> > production
> > > users of Geode and GemFire for in memory data management, and related
> > > projects.
> > >
> > > Attendees will also learn where the Geode project development is headed
> > > and how companies are using Geode. Check back soon as we will be
> updating
> > > the site with a detailed agenda once the speaker proposals have been
> > > selected.
> > >
> > > *Register Here: **https://2016.event.geodesummit.com/register
> > > *
> > >
> > > *Call for Proposals is Open*
> > >
> > > We are looking for users of the Apache Geode and GemFire community who
> > > would like to present 30 minute sessions and demos in any of the
> > following
> > > topics:
> > >
> > >-  Business and technical use cases
> > >-  Administration & deployment best practices
> > >-  Architecture and patterns
> > >-  Integration & ecosystem
> > >-  Tips, tricks, and how-to’s
> > >
> > > Please submit your contact information and abstract below.
> > >
> > > *Submit a talk here: **http://geodesummit.com/ <
> http://geodesummit.com/
> > >*
> > >
> > > --
> > > Greg Chase
> > >
> > > Director of Big Data Communities
> > > http://www.pivotal.io/big-data
> > >
> > > Pivotal Software
> > > http://www.pivotal.io/
> > >
> > > 650-215-0477
> > > @GregChase
> > > Blog: http://geekmarketing.biz/
> > >
> > >
> >
>
>
>
> --
> Greg Chase
>
> Director of Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Re: Please Join us for the Inagural Geode Summit - early bird pricing through Jan 31st!

[Dave Barnes]

Here's a sandbox site showing my changes:

http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/


On Fri, Jan 22, 2016 at 4:50 PM, William Markito <wmark...@pivotal.io>
wrote:

> Hey Dave,
>
> Apache mailing lists doesn't allow attachments so you might want to host it
> somewhere else like imgur and post the link here.
>
> It might also be interesting to submit a PR for review as an alternative to
> review and might you even be able to attach your screenshot there, but
> YMMV.
>
> Thanks!
>
> On Fri, Jan 22, 2016 at 3:10 PM Dave Barnes <dbar...@pivotal.io> wrote:
>
> > I don't have a handy place to install the full site, but here's a
> > screenshot of the events panel. If/when it looks OK to you, I'll submit a
> > pull request to have the changes put in place.
> > -Dave
> >
> >
> > On Fri, Jan 22, 2016 at 1:25 PM, Gregory Chase <gch...@pivotal.io>
> wrote:
> >
> >> Seattle JUG - Feb 16 http://www.seajug.org/
> >>
> >> On Fri, Jan 22, 2016 at 1:20 PM, Gregory Chase <gch...@pivotal.io>
> wrote:
> >>
> >> > Sunday, Jan 31st - FOSDEM
> >> > Mar 15 - Geode Clubhouse
> >> >
> >> > The Feb Clubhouse is still being set up.
> >> >
> >> > On Fri, Jan 22, 2016 at 1:17 PM, Gregory Chase <gch...@pivotal.io>
> >> wrote:
> >> >
> >> >> Oops, can't forget FOSDEM
> >> >>
> >> >> And more events get added here over time:
> >> >>
> >>
> https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles
> >> >>
> >> >> On Fri, Jan 22, 2016 at 1:16 PM, Gregory Chase <gch...@pivotal.io>
> >> wrote:
> >> >>
> >> >>> + Karen
> >> >>>
> >> >>> Lets just keep the dates Fresh.
> >> >>>
> >> >>> @Karen -> any more set dates we can add?
> >> >>>
> >> >>> On Fri, Jan 22, 2016 at 1:13 PM, Dave Barnes <dbar...@pivotal.io>
> >> wrote:
> >> >>>
> >> >>>> I can make this change, Greg.
> >> >>>> Shall I keep the old postings from 2015 events or start fresh?
> >> >>>>
> >> >>>> On Fri, Jan 22, 2016 at 12:08 PM, Gregory Chase <gch...@pivotal.io
> >
> >> >>>> wrote:
> >> >>>>
> >> >>>> > You are correct - needs to be updated.  Current website setup is
> a
> >> bit
> >> >>>> > challenging for non-developers to update.
> >> >>>> >
> >> >>>> > On Fri, Jan 22, 2016 at 12:05 PM, Mark Bretl <
> asf.mbr...@gmail.com
> >> >
> >> >>>> wrote:
> >> >>>> >
> >> >>>> > > Hi Greg,
> >> >>>> > >
> >> >>>> > > I don't see this event on the community site,
> >> >>>> > > http://geode.incubator.apache.org/community/#events, would you
> >> be
> >> >>>> able
> >> >>>> > to
> >> >>>> > > add it?
> >> >>>> > >
> >> >>>> > > --Mark
> >> >>>> > >
> >> >>>> > > On Thu, Jan 14, 2016 at 9:54 AM, Gregory Chase <
> >> gch...@pivotal.io>
> >> >>>> > wrote:
> >> >>>> > >
> >> >>>> > > > Pivotal Software is very excited to host this event for the
> >> Apache
> >> >>>> > Geode
> >> >>>> > > > (incubating) community:
> >> >>>> > > >
> >> >>>> > > > *Join Us!*
> >> >>>> > > >
> >> >>>> > > > *Pivotal, Palo Alto, CA|Wednesday, March 9, 2016*
> >> >>>> > > >
> >> >>>> > > > *Geode Summit Info Here: **http://geodesummit.com/
> >> >>>> > > > <http://geodesummit.com/>*
> >> >>>> > > >
> >> >>>> > > > The inaugural Geode Summit is a full day conference to bring
> >> >>>> together
> >> >>>> > the
> >> >>>> > > > Apache Geode (incubating) community 

Re: [VOTE] Apache Geode (Incubating) first Milestone release - v1.0.0-incubating.M1

[Dave Barnes]

+1 w/r/t copyright - single year policy is tried and tested in the pubs world, 
stands up to legal challenges. Note, however, that in some disputes the earlier 
date wins.

> On Jan 20, 2016, at 7:02 PM, Justin Erenkrantz  wrote:
> 
> On Tue, Jan 19, 2016 at 11:07 PM, Niall Pemberton
>  wrote:
>> Firstly, great job on producing the first RC. From an ASF release PoV, the
>> main concerns for me would be gemfire-joptsimple and the binary distro
>> NOTICE file and those stop me giving a +1 vote. From a user PoV the
>> dependencies in the maven pom look painful, trying to determine which can
>> safely be excluded.
>> 
>> 1. Source Distribution
>> * I checked the LICENSE, NOTICE & DISCLAIMER files were present
>> * The LICENSE file looks good
>> * The Copyright in the NOTICE file should be updated to "2015-2016"
> 
> As this is the first release, my suggestion would be to just have it
> be 2016.  In general, you should really only have one copyright year
> (the most recent one) - see what httpd does:
> 
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/NOTICE
> 
> I'm not sure why the docs on
> http://www.apache.org/legal/src-headers.html differ from what httpd
> does - a topic for legal-discuss@, I guess.  I'd just follow what
> httpd does and move on with life.
> 
> Cheers.  -- justin

Re: Open pull requests

[Dave Barnes]

Update index.html
#38 opened on Nov 18, 2015 by GregChase
PR #38 should be closed. I merged #38 with #36 into a later pull request,
#42, which was committed as part of the web page update.


On Thu, Jan 7, 2016 at 4:48 PM, Dan Smith  wrote:

> #29 caused test failures. I commented on that and I was hoping the author
> would pick that up and fix the failures, otherwise we may want to fix those
> and merge that at some point.
>
> -Dan
>
> On Thu, Jan 7, 2016 at 4:41 PM, Kirk Lund  wrote:
>
> > We have 6 pull requests that have been open for quite a while. Is someone
> > already working on each of these? What's the status on them?
> >
> > https://github.com/apache/incubator-geode/pulls
> >
> > Enabling direct reporting on Geode's website
> > #66 opened 10 days ago by rvs
> >
> > GEODE-341/ GEODE-628: Refactor Java packages to reflect Apache
> organization
> > /Rename container folder to "geode-jvsd"
> > #49 opened on Dec 8, 2015 by jujoramos
> >
> > Verified preceding content merges, fixed a couple of typos.
> > #47 opened on Dec 4, 2015 by davebarnes97
> >
> > Addresses the documentation component of GEODE-268, adding explanatio...
> > #43 opened on Nov 23, 2015 by davebarnes97
> >
> > Update index.html
> > #38 opened on Nov 18, 2015 by GregChase
> >
> > GEODE-252] Remove deprecated PartitionAttributes methods
> > #29 opened on Nov 5, 2015 by shroman
> >
>

Re: [DISCUSS] Generalized criteria for becoming an Apache Geode Committer

[Dave Barnes]

+1
I strongly agree with valuing quality over quantity - the former benefits
both product and community, the latter is too easily faked.

On Thu, Jan 7, 2016 at 8:50 AM, Roman Shaposhnik 
wrote:

> On Thu, Jan 7, 2016 at 8:48 AM, Kirk Lund  wrote:
> > It sounds like the process would then involve a current committer
> proposing
> > the new committer on private@geode and then voting on that list.
>
> This is typically a PMC's job to grow and manage the community. The
> proposal happens on the private@ ML and the voting happens there
> as well. Managing the community is one of the few times where formal
> voting is required in ASF (the other time is producing a release).
>
> Thanks,
> Roman.
>

Re: [VOTE] Added specific criteria for nomination and voting for new Committers to Apache Geode wiki

[Dave Barnes]

Grammar tweak - "the Apache Geode" didn't parse. I changed "follow the
development
process and community standards of the Apache Geode" to "follow the development
process and standards of the Apache Geode community".


On Thu, Jan 7, 2016 at 12:08 PM, Greg Chase  wrote:

> Revised per Dan's feedback, with my suggested phrasing:
>
> https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
>
> On Thu, Jan 7, 2016 at 11:59 AM, Gregory Chase  wrote:
>
> > I'm ok with striking existing #2.
> >
> > So maybe we rephrase the nomination criteria as an instruction to
> > Committers:
> >
> > New #2. Contributors are nominated by a Committer to be granted
> > Commit privileges by the Apache Geode PPMC.
> >
> > New #3. Committers should nominate fellow contributors when a candidate
> > has shown a consistent history of participating in the development
> process
> > or community, and has demonstrated that they understand and follow the
> > development process and community standards of the Apache Geode.
> >
> > On Thu, Jan 7, 2016 at 11:33 AM, Mark Bretl 
> wrote:
> >
> > > +1 For Dan's updates. I agree #2 does not help with understanding
> > criteria.
> > >
> > > --Mark
> > >
> > > On Thu, Jan 7, 2016 at 11:19 AM, Dan Smith  wrote:
> > >
> > > > Looks pretty good to me. I'd suggest a slight edit #3:
> > > >
> > > > Once a contributor shows a consistent history of participating in the
> > > > development process or community *and has demonstrated that they
> > > understand
> > > > the development process and standards can be trusted with commit
> > > access*, a
> > > > Committer should nominate them to the Apache Geode PPMC for
> > consideration
> > > > to become a Committer.
> > > >
> > > > I would remove #2 - it's a good point, but it's not really helping
> > > someone
> > > > understand what the criteria are for becoming a committer
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Jan 7, 2016 at 11:06 AM, Jens Deppe 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jan 7, 2016 at 10:49 AM, Greg Chase 
> > > wrote:
> > > > >
> > > > > > Greetings,
> > > > > > Per the discuss thread on this topic, I've added new text to our
> > wiki
> > > > > page
> > > > > > describing how to become a Committer.
> > > > > >
> > > > > > This text includes a generalized description of what I believe
> the
> > > > > > consensus is in the discussion thread.
> > > > > >
> > > > > > Changed page can be found here:
> > > > > >
> > > https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
> > > > > >
> > > > > > Lazy consensus applies.
> > > > > >
> > > > > > -Greg
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Greg Chase
> >
> > Director of Big Data Communities
> > http://www.pivotal.io/big-data
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> > Blog: http://geekmarketing.biz/
> >
>

Re: [VOTE] Added specific criteria for nomination and voting for new Committers to Apache Geode wiki

[Dave Barnes]

I like that. Re-edited to say "community standards of the Apache Geode
project."

On Thu, Jan 7, 2016 at 2:03 PM, Gregory Chase <gch...@pivotal.io> wrote:

> Thanks :)  I wrote "project" someplace, obviously not in the wiki itself :)
>
> On Thu, Jan 7, 2016 at 1:54 PM, Dave Barnes <dbar...@pivotal.io> wrote:
>
> > Grammar tweak - "the Apache Geode" didn't parse. I changed "follow the
> > development
> > process and community standards of the Apache Geode" to "follow the
> > development
> > process and standards of the Apache Geode community".
> >
> >
> > On Thu, Jan 7, 2016 at 12:08 PM, Greg Chase <g...@gregchase.com> wrote:
> >
> > > Revised per Dan's feedback, with my suggested phrasing:
> > >
> > > https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
> > >
> > > On Thu, Jan 7, 2016 at 11:59 AM, Gregory Chase <gch...@pivotal.io>
> > wrote:
> > >
> > > > I'm ok with striking existing #2.
> > > >
> > > > So maybe we rephrase the nomination criteria as an instruction to
> > > > Committers:
> > > >
> > > > New #2. Contributors are nominated by a Committer to be granted
> > > > Commit privileges by the Apache Geode PPMC.
> > > >
> > > > New #3. Committers should nominate fellow contributors when a
> candidate
> > > > has shown a consistent history of participating in the development
> > > process
> > > > or community, and has demonstrated that they understand and follow
> the
> > > > development process and community standards of the Apache Geode.
> > > >
> > > > On Thu, Jan 7, 2016 at 11:33 AM, Mark Bretl <asf.mbr...@gmail.com>
> > > wrote:
> > > >
> > > > > +1 For Dan's updates. I agree #2 does not help with understanding
> > > > criteria.
> > > > >
> > > > > --Mark
> > > > >
> > > > > On Thu, Jan 7, 2016 at 11:19 AM, Dan Smith <dsm...@pivotal.io>
> > wrote:
> > > > >
> > > > > > Looks pretty good to me. I'd suggest a slight edit #3:
> > > > > >
> > > > > > Once a contributor shows a consistent history of participating in
> > the
> > > > > > development process or community *and has demonstrated that they
> > > > > understand
> > > > > > the development process and standards can be trusted with commit
> > > > > access*, a
> > > > > > Committer should nominate them to the Apache Geode PPMC for
> > > > consideration
> > > > > > to become a Committer.
> > > > > >
> > > > > > I would remove #2 - it's a good point, but it's not really
> helping
> > > > > someone
> > > > > > understand what the criteria are for becoming a committer
> > > > > >
> > > > > > -Dan
> > > > > >
> > > > > > On Thu, Jan 7, 2016 at 11:06 AM, Jens Deppe <jde...@pivotal.io>
> > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Thu, Jan 7, 2016 at 10:49 AM, Greg Chase <
> g...@gregchase.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Greetings,
> > > > > > > > Per the discuss thread on this topic, I've added new text to
> > our
> > > > wiki
> > > > > > > page
> > > > > > > > describing how to become a Committer.
> > > > > > > >
> > > > > > > > This text includes a generalized description of what I
> believe
> > > the
> > > > > > > > consensus is in the discussion thread.
> > > > > > > >
> > > > > > > > Changed page can be found here:
> > > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
> > > > > > > >
> > > > > > > > Lazy consensus applies.
> > > > > > > >
> > > > > > > > -Greg
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Greg Chase
> > > >
> > > > Director of Big Data Communities
> > > > http://www.pivotal.io/big-data
> > > >
> > > > Pivotal Software
> > > > http://www.pivotal.io/
> > > >
> > > > 650-215-0477
> > > > @GregChase
> > > > Blog: http://geekmarketing.biz/
> > > >
> > >
> >
>
>
>
> --
> Greg Chase
>
> Director of Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>

Re: LICENSE and NOTICE

[Dave Barnes]

Where can I find these files?

On Mon, Jan 4, 2016 at 7:16 AM, Anthony Baker  wrote:

> I’ve made a start on our LICENSE and NOTICE files (for both source and
> binary distributions) on the feature/GEODE-610 branch.  Thanks to Niall for
> the excellent analysis to get this started.  If you’d like to contribute to
> this you can:
>
> 1) Review the contents of the LICENSE files and see if they look right.
> 2) Figure out what needs to go in the NOTICE files.
>
> This is needed for the alpha1 release.
>
> Thanks,
> Anthony
>
>

Re: [GitHub] incubator-geode pull request: Enabling direct reporting on Geode's...

[Dave Barnes]

I like having a functional button above the fold.
Is this too easy? Any limitations on who can report a bug?

On Mon, Dec 28, 2015 at 4:04 PM, Roman Shaposhnik 
wrote:

> Guys, please take a look at this one. I think adding it to the website
> would provide a nice touch. If spammy JIRAs ever become a problem
> we can disable it, of course.
>
> Oh, and the look-n-feel of the screen itself can be customized via ASF
> JIRA.
>
> Thanks,
> Roman.
>
>
> -- Forwarded message --
> From: rvs 
> Date: Mon, Dec 28, 2015 at 3:58 PM
> Subject: [GitHub] incubator-geode pull request: Enabling direct
> reporting on Geode's...
> To: dev@geode.incubator.apache.org
>
>
> GitHub user rvs opened a pull request:
>
> https://github.com/apache/incubator-geode/pull/66
>
> Enabling direct reporting on Geode's website
>
> This enables the vertical widget on the right hand side of the
> website similar to what's available on CouchDB's website
> http://couchdb.apache.org/
>
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/rvs/incubator-geode asf-site
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/incubator-geode/pull/66.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #66
>
> 
> commit 499de3fe4e3f850ecfdc53829f6b46ce8b9e3664
> Author: Roman Shaposhnik 
> Date:   2015-12-28T23:57:25Z
>
> Enabling direct reporting on Geode's website
>
> 
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: New Geode website - Latest changes

[Dave Barnes]

Total immersion ;)

> On Dec 7, 2015, at 7:46 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> 
>> On Mon, Dec 7, 2015 at 4:47 PM, Dave Barnes <dbar...@pivotal.io> wrote:
>> change "karma" to "good karma".
> 
> Good point! I guess you know your samsara well ;-)
> 
> Thanks,
> Roman.

Re: Final updates to Geode Website - Ready ?

[Dave Barnes]

Greg - William's message explains the problem. I had the directories
reversed - I thought .../website/content was the compiled version. You
should see all of your PR #38 changes in the final result, modified only
slightly by my proofreader's tweaks.
Will review when I'm in the office again next week to make sure things
happened as intended.
-Dave

On Wed, Nov 25, 2015 at 11:26 AM, William Markito 
wrote:

> Just updated including the latest changes from Greg and moved the
> Incubation disclaimer to About the Project as Roman suggested.
>
> Please try again: http://markito.github.io/geode-website/  and clean your
> caches.
>
> About the missing changes that Greg talked about,  he and Dave were
> updating the "compiled" website and not the source so their changes were
> being overridden. I'll update our instructions to avoid the problem in the
> future.   In summary, *always* change something under
> "gemfire-site/website/content" and *never *under "gemfire-site/content"
>
> Thanks for the feedback and let's restart the voting please.
>
>
> On Wed, Nov 25, 2015 at 11:20 AM, Jianxia Chen  wrote:
>
> > +1
> >
> > On Tue, Nov 24, 2015 at 10:30 PM, William Markito 
> > wrote:
> >
> > > I've just pushed the latest fixes and added content to the community
> page
> > > as well.
> > >
> > > Please check the result here ->
> http://markito.github.io/geode-website/
> > > (clear your cache)
> > >
> > > From my point of view and based on the feedback I got so far, this is
> > > *ready* to be pushed to asf-site and update our current website.
> > >
> > > Please let me know if you think otherwise, have any comments or
> feedback.
> > >
> > > Thanks,
> > > --
> > >
> > > William Markito Oliveira
> > > -- For questions about Apache Geode, please write to
> > > *dev@geode.incubator.apache.org
> > > *
> > >
> >
>
>
>
> --
>
> William Markito Oliveira
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> *
>

Permissions request

[Dave Barnes]

I'm a Pivotal tech writer (aka content developer), and plan to work on the
Geode javadocs. I'd like to request a bump in permissions so friends and
foes can assign me JIRA issues. Of particular interest would be issue
GEODE-54, but there will undoubtedly be others.
Thanks,
-Dave Barnes
dbar...@pivotal.io
Apache ID: dbarnes97

Re: [internal] Staged Geode website refresh - feedback puhlease

[Dave Barnes]

Greg,
My comments:
- Clean lines, useful links, it's been my go-to Geode start page since you
published it.
- I agree with Anthony w/r/t content

Layout issues:
- All the useful links are way at the bottom, have to scroll to get there.
Better if they could be on the initial screen view.
- Perhaps over-generous on the vertical whitespace (contributes to the
scrolling issue)
- Perhaps over-generaou on the font size, as well
- Readable on my iPhone, but the three-columns in the center look mighty
skinny. This is low-priority in my opinion.

Good work!
-Dave Barnes

On Wed, Oct 28, 2015 at 4:56 PM, Roman Shaposhnik <rshaposh...@pivotal.io>
wrote:

> Can we please have that feedback discussion on dev@geode ?
>
> Thanks,
> Roman.
>
> On Wed, Oct 28, 2015 at 4:52 PM, Anthony Baker <aba...@pivotal.io> wrote:
> > Greg, thanks for getting this moving.  It’s a big step forward!
> >
> > Comments, IMO:
> >
> > 1) Remove link to ‘Website on GitHub’
> >
> > 2) Remove comma after ' automated, ‘
> >
> > 3) This text seems lost:
> >
> > Processing low latency queries,
> > transactions, and data event messaging at high concurrency
> >
> > 4) The following text reads more like trivia than relevant content for
> someone trying to understand GemFire.  I think it would be more useful to
> call out typical GemFire use cases.
> >
> > Apache Geode (incubating) was first developed to solve performance
> issues at scale for commodities traders after the crash of Enron in 2002.
> It was released to the market as the commercial product GemFire, a product
> of Gemstone Systems. In April 2015, The code was granted to The ASF as
> Apache Geode (incubating).
> >
> > 5) Everything between ‘Mailing lists’ and ‘More…’ needs some design
> help.  What’s the intent of ‘More…’?
> >
> > Anthony
> >
> >
> >> On Oct 28, 2015, at 4:37 PM, Greg Chase <gch...@pivotal.io> wrote:
> >>
> >> Design only today became available to address some feedback on the wiki
> for icons.
> >>
> >> So few more days and I expose the site to the community for final
> comments and acceptance.
> >>
> >> This email encrypted by tiny buttons & fat thumbs, beta voice
> recognition, and autocorrect on my iPhone.
> >>
> >> On Oct 28, 2015, at 4:33 PM, Dormain Drewitz <ddrew...@pivotal.io>
> wrote:
> >>
> >>> it was going to be after Greenplum OSS
> >>>
> >>> On Wed, Oct 28, 2015 at 4:20 PM, Roman Shaposhnik <
> rshaposh...@pivotal.io> wrote:
> >>> When's the ASF Geode website getting updated?
> >>>
> >>> On Fri, Oct 23, 2015 at 4:50 PM, Gregory Chase <gch...@pivotal.io>
> wrote:
> >>> > Excellent feedback, Thank you David!
> >>> >
> >>> > On Fri, Oct 23, 2015 at 4:41 PM, David Yozie <dyo...@pivotal.io>
> wrote:
> >>> >>
> >>> >> Greg:  We recently moved the docs hosting site to
> geode.docs.pivotal.io,
> >>> >> in order to enable Google search.  The older
> http://geode-docs.cfapps.io/
> >>> >> site is still maintained, but we should probably be pointing
> everyone to
> >>> >> geode.docs.pivotal.io.
> >>> >>
> >>> >> -David
> >>> >>
> >>> >> On Fri, Oct 23, 2015 at 3:55 PM, Gregory Chase <gch...@pivotal.io>
> wrote:
> >>> >>>
> >>> >>> http://pivotalsoftware.github.io/geode-site/
> >>> >>>
> >>> >>> Just got it myself, so maybe some simple stuff too.
> >>> >>>
> >>> >>> --
> >>> >>> Greg Chase
> >>> >>>
> >>> >>> Director of Big Data Communities
> >>> >>> http://www.pivotal.io/big-data
> >>> >>>
> >>> >>> Pivotal Software
> >>> >>> http://www.pivotal.io/
> >>> >>>
> >>> >>> 650-215-0477
> >>> >>> @GregChase
> >>> >>> Blog: http://geekmarketing.biz/
> >>> >>>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Greg Chase
> >>> >
> >>> > Director of Big Data Communities
> >>> > http://www.pivotal.io/big-data
> >>> >
> >>> > Pivotal Software
> >>> > http://www.pivotal.io/
> >>> >
> >>> > 650-215-0477
> >>> > @GregChase
> >>> > Blog: http://geekmarketing.biz/
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Dormain Drewitz | Product Marketing | Pivotal
> >>> ddrew...@pivotal.io | m.415.335.8463 | twitter: @dormaindrewitz
> >
>

GEODE-188 Gfsh uses the wrong name for the gateway substitution filter in 'create async-event-queue' command

[Dave Barnes]

GEODE-188 has been fixed in code, so I'd like to update the docs.
The code fix was to replace "gateway-event-substitution-listener" with "
gateway-event-substitution-filter".
My questions:
1. Can someone please explain the purpose of gateway-event-substitution-filter?
I need to add a definition to the cache.xml documentation.
2. Is gateway-event-substitution-listener also a valid setting, which was
simply out of place in this case, or is it a totally bogus name? If valid,
can someone please explain this as well, so I can create a definition for
cache.xml purposes?
Thanks,
Dave Barnes
Sr. Content Dev, Pivotal