[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #114 was SUCCESSFUL (with 1214 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #114 was successful.
---
Scheduled
1218 tests in total.

https://build.spring.io/browse/SGF-NAG-114/





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 39879: Add gemfire-common and @Experimental annotation

[Dan Smith]

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

Ship it!


- Should this be consolodated with gemfire-junit?
- Or maybe we should have a gemfire-api project and move the rest of the public 
API there as well?

- Dan Smith


On Nov. 2, 2015, 9:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39879/
> ---
> 
> (Updated Nov. 2, 2015, 9:57 p.m.)
> 
> 
> Review request for geode, Anthony Baker, William Markito, and Mark Bretl.
> 
> 
> Bugs: GEODE-328
> https://issues.apache.org/jira/browse/GEODE-328
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Add new gemfire-common project containing code for Experimental annotation 
> under main and a UnitTest under test.
> 
> Add gemfire-common to gemfire-assembly for publishing.
> 
> Add dependency on gemfire-common to gemfire-core, gemfire-rebalancer, and 
> gemfire-web.
> 
> 
> Diffs
> -
> 
>   gemfire-assembly/build.gradle b351729 
>   gemfire-common/build.gradle PRE-CREATION 
>   
> gemfire-common/src/main/java/com/gemstone/gemfire/annotations/Experimental.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/ExperimentalJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/ClassInExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/package-info.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/ClassInNonExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/package-info.java
>  PRE-CREATION 
>   gemfire-core/build.gradle 1c17474 
>   gemfire-rebalancer/build.gradle d87dd58 
>   gemfire-web/build.gradle f0de25a 
>   settings.gradle 4b2da7b 
> 
> Diff: https://reviews.apache.org/r/39879/diff/
> 
> 
> Testing
> ---
> 
> clean build and unit testing of the new annotation
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Geode Definition of Done (DOD)

[Roman Shaposhnik]

First of all, I'm a huge +1 of having it all written down on a wiki.

An additional benefit of that checklist is that then you can use
it as a criteria for pulling functionality from feature branches
into the 'golden branch'.

I've seen this done very successfully in some of the other projects.

Thanks,
Roman.

On Mon, Nov 2, 2015 at 4:59 PM, Kirk Lund  wrote:
> I was just sharing the Spring Data DoD. The Apache Geode DoD would include
> CTR.
>
> The DoD is a checklist every developer follows when working on a User
> Story. If the DoD includes "UnitTests have been written and are passing"
> then the developer must complete that step before they can say "I'm done
> with this User Story".
>
> -Kirk
>
>
> On Mon, Nov 2, 2015 at 2:23 PM, Anthony Baker  wrote:
>
>> Practically speaking, when is the DOD used?  Also, how does this differ
>> from the contribution process?
>>
>> I don’t see a review (CTR) step.
>>
>> Anthony
>>
>>
>> > On Nov 2, 2015, at 1:33 PM, William Markito  wrote:
>> >
>> > +1
>> >
>> > Just one question, what is snapshot build deployed ? Is it the same as
>> > snapshot build successfully completed ?
>> >
>> > On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:
>> >
>> >> +1
>> >>
>> >> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
>> >> wrote:
>> >>
>> >>> +1
>> >>> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
>> >>>
>>  I think we need to settle on a formal Definition of Done (DOD) for
>> >> Apache
>>  Geode. Again, borrowing from Spring Data we could start with what they
>>  define and add to it:
>> 
>> 
>>    - Implemented according to specification in the ticket
>>    - Unit tested
>>    - Integration tested
>>    - Reference documentation updated
>>    - Changelog updated
>>    - Code formatted appropriately
>>    - JavaDoc polished
>>    - Feature branch merged into master [develop?]
>>    - Snapshot build deployed
>>    - Ticket closed
>> 
>> 
>>  https://github.com/spring-projects/spring-data-commons/wiki/DOD
>> 
>>  Any thoughts or feedback?
>> 
>>  -Kirk
>> 
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> -John
>> >> 503-504-8657
>> >> john.blum10101 (skype)
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > William Markito Oliveira
>> > -- For questions about Apache Geode, please write to
>> > *dev@geode.incubator.apache.org
>> > *
>>
>>

Review Request 39885: squash-a-thon week 2 fixes

[Darrel Schneider]

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

Review request for geode and Kirk Lund.


Repository: geode


Description
---

remove unused local var accidently added to unit test


GEODE-489: delegate in getRefCount

Certains subclasses of MemoryBlock do not have a refCount.
But the MemoryBlockNode implementation was always trying to
read a refCount using the memory address of the block.
Instead it should have delegated getRefCount to the MemoryBlock
implementation.

GEODE-464: Fix AutoBalancer test race condition

Instance of cache Initializer is not destroyed when the cache is destroyed. As a
result, a scheduled rebalance job can start after a different test starts. This
can cause failures. Add a destroy method to kill scheduler in test tearDown to
prevent orphaned tasks from failing other tests.

GEODE-361: fix expiry races in unit test

The test now uses WaitCriterion when waiting
for an expiration. Also it now configures
millisecond expiry so the test runs faster.

GEODE-244 Flush entries to disk in testRecoverRedundancyParallelAsyncEventQueue

The queue is configured for async persistence, which means entries were
being flushed to disk asynchronously. Due to GEODE-498, the size of the
buckets could vary widely if the entries were not flushed to disk,
causing the rebalance to have problems later.

GEODE-438: wait longer for event

Also the assertion messages now describe what the
test expects.

GEODE-367: wait longer for assertion

Also fixed assertion messages.

GEODE-452. We were checking cacheClientProxy after closing it. but sometimes 
client was reconnecting and queue again. Now we check after closing the client 
cache.


fixed GEODE-423 and GEODE-432. Now we start cacheserver using port 0. That will 
force cacheserver to find available port.


GEODE-502: Keeping a reference to RMI objects in the dunit framework

My suspicion with this failure is that the GC happened that cleaned up
one of these objects, if the RMI framework is not keeping a strong
reference to the class.

GEODE-467: fix race in off-heap memory monitor tests

I think this may have been caused by the monitor thread
continuing to run after the unit tests call stopMonitor.
They now call a flavor of the method that joins on the
monitor thread.

Fixes GEODE-495: fix for OffHeapManagementDUnitTest

- use a random port for the JMX manager
- fixed cleanup not to create cache if not created already

This closes #25

GEODE-469: Don't log a warning if a region is destroyed during creation

This test saw a suspect string because we logged a warning about a
RegionDestroyedException during region creation. I don't think this
warning should be logged, we don't log warnings for CancelExceptions.

GEODE-366: Wait for clear to be propegated in ClientHealthStatsDUnitTest

The clear was showing up asynchronously on the second client. By moving
the clear up before an existing wait, it should get to the second
client before that client does a put.

GEODE-501. test no-ack region thus we need to wait before validating the 
results.


GEODE-411: fix suspect string on disconnect

DistributionManager now has a isCloseInProgress method
that checks both the volatile closeInProgress boolean
and ask its DistributedSystem if it is disconnecting.
This new method is used in places that decide if a warning
should be logged.

GEODE-453: Ignoring suspect string in testRegisterInterestNoDataStores

Another suspect string from the same method.

Revert "GEODE-467: fix race in off-heap memory monitor tests"

This reverts commit 9d8e568b4b00085b5f2cf8b7d049027211b3f7d1. This
commit was causing the dunit runs to hang in stopMonitoring.

GEODE-467: fix race in off-heap memory monitor tests

Fixed the hang in testHeapLRUWithOverflowToDisk.
It turned out that in many cases the off-heap memory
usage listener thread was never terminating.
So when this test waited for it to terminate it hung.

[fixes GEODE-493] Fixes a race that an async thread not yet updating the PR 
metadata.


GEODE-371: The unfinished destroy operation is overwritten by the GII but the 
tombstone is left in cache. TombstoneGC on different members are not finished 
at the same time. When GII happened in this window, the expected deltaGII will 
become full GII.

However, after discussed with the team, we decide not to fix, only to enhance
the test to wait until the time window is over.

GEODE-513:

add expected exceptions for the exception test.

Include nested exception


GEODE-512: fix unit test suspect string reporter

A couple of problems that have been fixed:
1. If a stack has a "caused by" it will now be included
in the suspect string report.
2. Warning messages were only being partly ignored.
Now they are completely ignored. At some point in the
future we should consider treating a warning message
like error and severe messages.

Re: Geode Definition of Done (DOD)

[Kirk Lund]

I was just sharing the Spring Data DoD. The Apache Geode DoD would include
CTR.

The DoD is a checklist every developer follows when working on a User
Story. If the DoD includes "UnitTests have been written and are passing"
then the developer must complete that step before they can say "I'm done
with this User Story".

-Kirk


On Mon, Nov 2, 2015 at 2:23 PM, Anthony Baker  wrote:

> Practically speaking, when is the DOD used?  Also, how does this differ
> from the contribution process?
>
> I don’t see a review (CTR) step.
>
> Anthony
>
>
> > On Nov 2, 2015, at 1:33 PM, William Markito  wrote:
> >
> > +1
> >
> > Just one question, what is snapshot build deployed ? Is it the same as
> > snapshot build successfully completed ?
> >
> > On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:
> >
> >> +1
> >>
> >> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
> >> wrote:
> >>
> >>> +1
> >>> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
> >>>
>  I think we need to settle on a formal Definition of Done (DOD) for
> >> Apache
>  Geode. Again, borrowing from Spring Data we could start with what they
>  define and add to it:
> 
> 
>    - Implemented according to specification in the ticket
>    - Unit tested
>    - Integration tested
>    - Reference documentation updated
>    - Changelog updated
>    - Code formatted appropriately
>    - JavaDoc polished
>    - Feature branch merged into master [develop?]
>    - Snapshot build deployed
>    - Ticket closed
> 
> 
>  https://github.com/spring-projects/spring-data-commons/wiki/DOD
> 
>  Any thoughts or feedback?
> 
>  -Kirk
> 
> >>>
> >>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657
> >> john.blum10101 (skype)
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
>
>

Re: Geode Definition of Done (DOD)

[Kirk Lund]

The DoD is a checklist with everything that needs to be done in order to
say you're done with a User Story, Iteration, or Release. Most contributors
would be primarily interested in DoD for User Story, but some projects add
additional steps to the DoD for Iterations and Releases (such as Capturing
Release Notes).

Defining "done" simply formalizes what it means to be done. Without
defining done, important work can easily be skipped accidentally or
purposefully (Javadocs, User Docs/Manual, UnitTests, IntegrationTests,
AcceptanceTests, product examples, license audit, crypto audit, etc). For
an open source project, it's extremely valuable to have a DoD so that new
contributors know what all needs to happen to contribute successfully.

The DoD should be a live document that is continually reviewed and improved
as needed. It would simply be a page on the wiki that mentions things like
writing UnitTests, reviewing changes prior to committing, etc.

Unless someone else wants to, I'll write up a draft tomorrow on the wiki
and then others can comment or modify.

Good definition of Done in Jira:
http://blogs.atlassian.com/2013/10/8-steps-to-a-definition-of-done-in-jira/

Interesting blog article about Multiple Levels of Done:
https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done

Good article about DoD:
https://dzone.com/articles/definitions-done-practice

Another good article:
http://sauceio.com/index.php/2015/09/what-is-your-definition-of-done/

-Kirk


On Mon, Nov 2, 2015 at 3:38 PM, John Blum  wrote:

> DoD is used continuously especially before a release goes out.  DoD occurs
> continuously with activities such as design, implementation, testing,
> documenting, merging (topic branches), getting feedback, iterating, etc.
> Other activities (Code Formatting, Polishing, Ticket Closing, etc) are
> "tie-up" tasks and necessarily happen at the end, right before a release.
>
> As for the "contribution process", there is not much difference.  A JIRA
> ticket is filed for the PR (especially for not committers) and the ticket
> progresses as any other ticket would.
>
> Finally, most Spring projects doe not have the luxury of having a
> "reviewer", mostly because there are 1 to many projects per engineer.  Some
> projects like the core Spring Framework, Spring Boot, Spring XD, Spring
> Cloud, etc, have a lot more eyes on it and so they do involve a more formal
> review process.  On the Spring Data team, for instance, Oliver is trying to
> have everyone work on minimally 2 SD modules.  That way, each engineer has
> someone who is familiar with the project and can share ideas with the other
> (a sanity check).
>
> But, for the most part, review, like refactoring, is something that needs
> to be continuous.  Besides, the code is never done, really, ;-)
>
> -j
>
>
> On Mon, Nov 2, 2015 at 2:23 PM, Anthony Baker  wrote:
>
> > Practically speaking, when is the DOD used?  Also, how does this differ
> > from the contribution process?
> >
> > I don’t see a review (CTR) step.
> >
> > Anthony
> >
> >
> > > On Nov 2, 2015, at 1:33 PM, William Markito 
> wrote:
> > >
> > > +1
> > >
> > > Just one question, what is snapshot build deployed ? Is it the same as
> > > snapshot build successfully completed ?
> > >
> > > On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:
> > >
> > >> +1
> > >>
> > >> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer  >
> > >> wrote:
> > >>
> > >>> +1
> > >>> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
> > >>>
> >  I think we need to settle on a formal Definition of Done (DOD) for
> > >> Apache
> >  Geode. Again, borrowing from Spring Data we could start with what
> they
> >  define and add to it:
> > 
> > 
> >    - Implemented according to specification in the ticket
> >    - Unit tested
> >    - Integration tested
> >    - Reference documentation updated
> >    - Changelog updated
> >    - Code formatted appropriately
> >    - JavaDoc polished
> >    - Feature branch merged into master [develop?]
> >    - Snapshot build deployed
> >    - Ticket closed
> > 
> > 
> >  https://github.com/spring-projects/spring-data-commons/wiki/DOD
> > 
> >  Any thoughts or feedback?
> > 
> >  -Kirk
> > 
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> -John
> > >> 503-504-8657
> > >> john.blum10101 (skype)
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > William Markito Oliveira
> > > -- For questions about Apache Geode, please write to
> > > *dev@geode.incubator.apache.org
> > > *
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Re: Review Request 39445: GEODE-12/GEODE-304 Fix Pulse tests

[Dick Cavender]

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

Ship it!


Ship It!

- Dick Cavender


On Oct. 28, 2015, 4:29 a.m., Nitin Lamba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39445/
> ---
> 
> (Updated Oct. 28, 2015, 4:29 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Tushar Khairnar, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This includes several clean-ups for Pulse tests including:
> - Build gradle (to invoke the right set of tests)
> - Pulse JMX test beans update based on Geode JMX changes in recent releases
> - Test references (corrected or ignored)
> 
> This is set of 3 commits on feature/GEODE-12 branch.
> 
> 
> Diffs
> -
> 
>   pulse/build.gradle b2bd5fc 
>   
> pulse/src/main/java/com/vmware/gemfire/tools/pulse/internal/data/JMXDataUpdater.java
>  27aed67 
>   pulse/src/main/resources/pulse.properties 17299c2 
>   pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/Member.java 
> 812e055 
>   
> pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAutomatedTests.java
>  21c14d5 
>   pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseTestData.java 
> d1a92a2 
>   pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseTests.java 
> b6dd7c6 
>   
> pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/RegionOnMember.java 
> 7402a8b 
>   pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/ServerObject.java 
> 97acac7 
>   
> pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/ServerObjectMBean.java
>  9487c0e 
>   pulse/src/test/resources/test.properties fabeea1 
> 
> Diff: https://reviews.apache.org/r/39445/diff/
> 
> 
> Testing
> ---
> 
> Tested with the latest Firefox browser 41.0.2.
> All UI tests pass.
> 
> 
> File Attachments
> 
> 
> Patch_02 - JUnit & gradle updates
>   
> https://reviews.apache.org/media/uploaded/files/2015/10/28/4a2bf570-14f8-458d-9cc6-529d0f9b8f77__patch_02.diff
> Patch_03 - Test clean-up & fixes
>   
> https://reviews.apache.org/media/uploaded/files/2015/10/28/b5497b9a-8742-46e8-870e-a16e8622cebc__patch_03.diff
> 
> 
> Thanks,
> 
> Nitin Lamba
> 
>

Re: Review Request 39879: Add gemfire-common and @Experimental annotation

[William Markito]

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

Ship it!


Ship It!

- William Markito


On Nov. 2, 2015, 9:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39879/
> ---
> 
> (Updated Nov. 2, 2015, 9:57 p.m.)
> 
> 
> Review request for geode, Anthony Baker, William Markito, and Mark Bretl.
> 
> 
> Bugs: GEODE-328
> https://issues.apache.org/jira/browse/GEODE-328
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Add new gemfire-common project containing code for Experimental annotation 
> under main and a UnitTest under test.
> 
> Add gemfire-common to gemfire-assembly for publishing.
> 
> Add dependency on gemfire-common to gemfire-core, gemfire-rebalancer, and 
> gemfire-web.
> 
> 
> Diffs
> -
> 
>   gemfire-assembly/build.gradle b351729 
>   gemfire-common/build.gradle PRE-CREATION 
>   
> gemfire-common/src/main/java/com/gemstone/gemfire/annotations/Experimental.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/ExperimentalJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/ClassInExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/package-info.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/ClassInNonExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/package-info.java
>  PRE-CREATION 
>   gemfire-core/build.gradle 1c17474 
>   gemfire-rebalancer/build.gradle d87dd58 
>   gemfire-web/build.gradle f0de25a 
>   settings.gradle 4b2da7b 
> 
> Diff: https://reviews.apache.org/r/39879/diff/
> 
> 
> Testing
> ---
> 
> clean build and unit testing of the new annotation
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Geode Definition of Done (DOD)

[John Blum]

DoD is used continuously especially before a release goes out.  DoD occurs
continuously with activities such as design, implementation, testing,
documenting, merging (topic branches), getting feedback, iterating, etc.
Other activities (Code Formatting, Polishing, Ticket Closing, etc) are
"tie-up" tasks and necessarily happen at the end, right before a release.

As for the "contribution process", there is not much difference.  A JIRA
ticket is filed for the PR (especially for not committers) and the ticket
progresses as any other ticket would.

Finally, most Spring projects doe not have the luxury of having a
"reviewer", mostly because there are 1 to many projects per engineer.  Some
projects like the core Spring Framework, Spring Boot, Spring XD, Spring
Cloud, etc, have a lot more eyes on it and so they do involve a more formal
review process.  On the Spring Data team, for instance, Oliver is trying to
have everyone work on minimally 2 SD modules.  That way, each engineer has
someone who is familiar with the project and can share ideas with the other
(a sanity check).

But, for the most part, review, like refactoring, is something that needs
to be continuous.  Besides, the code is never done, really, ;-)

-j


On Mon, Nov 2, 2015 at 2:23 PM, Anthony Baker  wrote:

> Practically speaking, when is the DOD used?  Also, how does this differ
> from the contribution process?
>
> I don’t see a review (CTR) step.
>
> Anthony
>
>
> > On Nov 2, 2015, at 1:33 PM, William Markito  wrote:
> >
> > +1
> >
> > Just one question, what is snapshot build deployed ? Is it the same as
> > snapshot build successfully completed ?
> >
> > On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:
> >
> >> +1
> >>
> >> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
> >> wrote:
> >>
> >>> +1
> >>> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
> >>>
>  I think we need to settle on a formal Definition of Done (DOD) for
> >> Apache
>  Geode. Again, borrowing from Spring Data we could start with what they
>  define and add to it:
> 
> 
>    - Implemented according to specification in the ticket
>    - Unit tested
>    - Integration tested
>    - Reference documentation updated
>    - Changelog updated
>    - Code formatted appropriately
>    - JavaDoc polished
>    - Feature branch merged into master [develop?]
>    - Snapshot build deployed
>    - Ticket closed
> 
> 
>  https://github.com/spring-projects/spring-data-commons/wiki/DOD
> 
>  Any thoughts or feedback?
> 
>  -Kirk
> 
> >>>
> >>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657
> >> john.blum10101 (skype)
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Review Request 39825: GEODE-520: GFSH Alter Region entry-time-to-live-expiration causes subsequent server restart to fail.

[Darrel Schneider]

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

Ship it!


Ship It!

- Darrel Schneider


On Oct. 30, 2015, 3:10 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39825/
> ---
> 
> (Updated Oct. 30, 2015, 3:10 p.m.)
> 
> 
> Review request for geode and Darrel Schneider.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-520: GFSH Alter Region entry-time-to-live-expiration causes subsequent 
> server restart to fail.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/AttributesFactory.java 
> 6af21b1abc1b0084be7917af61c83a2c94b629f2 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegion.java
>  ed5a39044bba1dff1736e109c4d16a2fa46a9c2e 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/PartitionedRegion.java
>  ce50c5276c208a6a169cc390ea31993c3a0b1fd9 
>   gemfire-core/src/test/java/com/gemstone/gemfire/cache30/RegionTestCase.java 
> f5b4ab28058352f131669a642884d0993a4a74d9 
> 
> Diff: https://reviews.apache.org/r/39825/diff/
> 
> 
> Testing
> ---
> 
> Ran the following DUnits which all extend RegionTestCase
> 
> DiskDistributedNoAckAsyncOverflowRegionDUnitTest
> DiskDistributedNoAckAsyncRegionDUnitTest
> DiskDistributedNoAckSyncOverflowRegionDUnitTest
> DistributedAckOverflowRegionCCECompressionDUnitTest
> DistributedAckOverflowRegionCCEDUnitTest
> DistributedAckOverflowRegionCCEOffHeapDUnitTest
> DistributedAckPersistentRegionCCECompressionDUnitTest
> DistributedAckPersistentRegionCCEDUnitTest
> DistributedAckPersistentRegionCCEOffHeapDUnitTest
> DistributedAckRegionCCEDUnitTest
> DistributedAckRegionCCEOffHeapDUnitTest
> DistributedAckRegionCompressionDUnitTest
> DistributedAckRegionDUnitTest
> DistributedAckRegionOffHeapDUnitTest
> DistributedNoAckRegionCCEDUnitTest
> DistributedNoAckRegionCCEOffHeapDUnitTest
> DistributedNoAckRegionCompressionDUnitTest
> DistributedNoAckRegionDUnitTest
> DistributedNoAckRegionOffHeapDUnitTest
> GlobalRegionCCEDUnitTest
> GlobalRegionCCEOffHeapDUnitTest
> GlobalRegionCompressionDUnitTest
> GlobalRegionDUnitTest
> GlobalRegionOffHeapDUnitTest
> LocalRegionDUnitTest
> PartitionedRegionCompressionDUnitTest
> PartitionedRegionDUnitTest
> PartitionedRegionOffHeapDUnitTest
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: JIRA Resolved vs Closed

[Ashvin A]

+1

Using Closed state for change log makes sense. Will the release manager
make the transition from Resolved to Closed state after a release?

Thanks,
Ashvin

On Mon, Nov 2, 2015 at 2:19 PM, Anthony Baker  wrote:

> Echoing the logic:
>
> http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200605.mbox/%3c447d2230.5020...@apache.org%3E
>
> Anthony
>
> > On Nov 2, 2015, at 12:43 PM, John Blum  wrote:
> >
> > +1
> >
> > To add a bit of clarification on the Resolved vs. Closed status, you can
> > also think of Closed as the moment the customer/user considers the
> > issue/enhancement identified in the JIRA as complete and "accepted".
> Since
> > most OSS projects do not have a specific user/customer, then a ticket is
> > considered closed once released to indicate there were no additional
> follow
> > up on the ticket keeping it in an "in-progress" status and holding up the
> > release.  This is not to say that a ticket cannot be "re-opened" at a
> later
> > time if another related problem is found.  However, it usually up to
> > individual projects to decide whether to re-open the existing ticket or
> > just file a new one (and link back to the original).
> >
> > -j
> >
> >
> > On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund  wrote:
> >
> >> Is there a standard that ASF follows for when a JIRA ticket changes
> status
> >> to Resolved vs Closed?
> >>
> >> If not, then I'd like recommend that we follow the process that Spring
> >> uses:
> >>
> >> Ticket changes to Resolved when the fix/implementation is committed or
> >> merged (to develop in our case). It then moves to Closed when that fix
> or
> >> implementation ships in a release. The two different states then have
> >> meaning and purpose as well as having a clear definition of when a
> ticket
> >> should be Resolved vs Closed.
> >>
> >> If a bug actually originates on a branch and is then Resolved on that
> same
> >> branch before merging anywhere, we could then specify that the ticket
> >> should be Closed before merging to develop.
> >>
> >> Thoughts or feedback?
> >>
> >> -Kirk
> >>
> >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
>
>

Re: Geode Definition of Done (DOD)

[Anthony Baker]

Practically speaking, when is the DOD used?  Also, how does this differ from 
the contribution process?

I don’t see a review (CTR) step.

Anthony


> On Nov 2, 2015, at 1:33 PM, William Markito  wrote:
> 
> +1
> 
> Just one question, what is snapshot build deployed ? Is it the same as
> snapshot build successfully completed ?
> 
> On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:
> 
>> +1
>> 
>> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
>> wrote:
>> 
>>> +1
>>> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
>>> 
 I think we need to settle on a formal Definition of Done (DOD) for
>> Apache
 Geode. Again, borrowing from Spring Data we could start with what they
 define and add to it:
 
 
   - Implemented according to specification in the ticket
   - Unit tested
   - Integration tested
   - Reference documentation updated
   - Changelog updated
   - Code formatted appropriately
   - JavaDoc polished
   - Feature branch merged into master [develop?]
   - Snapshot build deployed
   - Ticket closed
 
 
 https://github.com/spring-projects/spring-data-commons/wiki/DOD
 
 Any thoughts or feedback?
 
 -Kirk
 
>>> 
>> 
>> 
>> 
>> --
>> -John
>> 503-504-8657
>> john.blum10101 (skype)
>> 
> 
> 
> 
> --
> 
> William Markito Oliveira
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> *



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: JIRA Resolved vs Closed

[Anthony Baker]

Echoing the logic:
http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200605.mbox/%3c447d2230.5020...@apache.org%3E

Anthony

> On Nov 2, 2015, at 12:43 PM, John Blum  wrote:
> 
> +1
> 
> To add a bit of clarification on the Resolved vs. Closed status, you can
> also think of Closed as the moment the customer/user considers the
> issue/enhancement identified in the JIRA as complete and "accepted".  Since
> most OSS projects do not have a specific user/customer, then a ticket is
> considered closed once released to indicate there were no additional follow
> up on the ticket keeping it in an "in-progress" status and holding up the
> release.  This is not to say that a ticket cannot be "re-opened" at a later
> time if another related problem is found.  However, it usually up to
> individual projects to decide whether to re-open the existing ticket or
> just file a new one (and link back to the original).
> 
> -j
> 
> 
> On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund  wrote:
> 
>> Is there a standard that ASF follows for when a JIRA ticket changes status
>> to Resolved vs Closed?
>> 
>> If not, then I'd like recommend that we follow the process that Spring
>> uses:
>> 
>> Ticket changes to Resolved when the fix/implementation is committed or
>> merged (to develop in our case). It then moves to Closed when that fix or
>> implementation ships in a release. The two different states then have
>> meaning and purpose as well as having a clear definition of when a ticket
>> should be Resolved vs Closed.
>> 
>> If a bug actually originates on a branch and is then Resolved on that same
>> branch before merging anywhere, we could then specify that the ticket
>> should be Closed before merging to develop.
>> 
>> Thoughts or feedback?
>> 
>> -Kirk
>> 
> 
> 
> 
> --
> -John
> 503-504-8657
> john.blum10101 (skype)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review Request 39879: Add gemfire-common and @Experimental annotation

[Kirk Lund]

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



gemfire-web/build.gradle (line 15)


I think this change was added to the diff by latest down-merge of develop 
HEAD to my branch. Let me know which is correct (testRuntime or provided).


- Kirk Lund


On Nov. 2, 2015, 9:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39879/
> ---
> 
> (Updated Nov. 2, 2015, 9:57 p.m.)
> 
> 
> Review request for geode, Anthony Baker, William Markito, and Mark Bretl.
> 
> 
> Bugs: GEODE-328
> https://issues.apache.org/jira/browse/GEODE-328
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Add new gemfire-common project containing code for Experimental annotation 
> under main and a UnitTest under test.
> 
> Add gemfire-common to gemfire-assembly for publishing.
> 
> Add dependency on gemfire-common to gemfire-core, gemfire-rebalancer, and 
> gemfire-web.
> 
> 
> Diffs
> -
> 
>   gemfire-assembly/build.gradle b351729 
>   gemfire-common/build.gradle PRE-CREATION 
>   
> gemfire-common/src/main/java/com/gemstone/gemfire/annotations/Experimental.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/ExperimentalJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/ClassInExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/package-info.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/ClassInNonExperimentalPackage.java
>  PRE-CREATION 
>   
> gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/package-info.java
>  PRE-CREATION 
>   gemfire-core/build.gradle 1c17474 
>   gemfire-rebalancer/build.gradle d87dd58 
>   gemfire-web/build.gradle f0de25a 
>   settings.gradle 4b2da7b 
> 
> Diff: https://reviews.apache.org/r/39879/diff/
> 
> 
> Testing
> ---
> 
> clean build and unit testing of the new annotation
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 39877: GEODE-522: Fix eclipse classpath for generation of IDE project files

[Dan Smith]

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


As we discussed, we don't want to add any of the gradle output directories to 
the gemfire-web project in eclipse. It should depend only on the gemfire-core 
project and some number of jars, not on gemfire-core/build/classes, etc.

- Dan Smith


On Nov. 2, 2015, 9:38 p.m., Mark Bretl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39877/
> ---
> 
> (Updated Nov. 2, 2015, 9:38 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Kirk Lund, and Dan Smith.
> 
> 
> Bugs: GEODE-522
> https://issues.apache.org/jira/browse/GEODE-522
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-522: Fix eclipse classpath for generation of IDE project files
> 
> 
> Diffs
> -
> 
>   gemfire-web/build.gradle f0de25aa9af036442ce115c82e2b7193504a5236 
> 
> Diff: https://reviews.apache.org/r/39877/diff/
> 
> 
> Testing
> ---
> 
> 'clean eclipse' then import into Spring Tool Suite 3.7.1
> 
> 
> Thanks,
> 
> Mark Bretl
> 
>

Review Request 39879: Add gemfire-common and @Experimental annotation

[Kirk Lund]

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

Review request for geode, Anthony Baker, William Markito, and Mark Bretl.


Bugs: GEODE-328
https://issues.apache.org/jira/browse/GEODE-328


Repository: geode


Description
---

Add new gemfire-common project containing code for Experimental annotation 
under main and a UnitTest under test.

Add gemfire-common to gemfire-assembly for publishing.

Add dependency on gemfire-common to gemfire-core, gemfire-rebalancer, and 
gemfire-web.


Diffs
-

  gemfire-assembly/build.gradle b351729 
  gemfire-common/build.gradle PRE-CREATION 
  
gemfire-common/src/main/java/com/gemstone/gemfire/annotations/Experimental.java 
PRE-CREATION 
  
gemfire-common/src/test/java/com/gemstone/gemfire/annotations/ExperimentalJUnitTest.java
 PRE-CREATION 
  
gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/ClassInExperimentalPackage.java
 PRE-CREATION 
  
gemfire-common/src/test/java/com/gemstone/gemfire/annotations/experimentalpackage/package-info.java
 PRE-CREATION 
  
gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/ClassInNonExperimentalPackage.java
 PRE-CREATION 
  
gemfire-common/src/test/java/com/gemstone/gemfire/experimental/nonexperimentalpackage/package-info.java
 PRE-CREATION 
  gemfire-core/build.gradle 1c17474 
  gemfire-rebalancer/build.gradle d87dd58 
  gemfire-web/build.gradle f0de25a 
  settings.gradle 4b2da7b 

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


Testing
---

clean build and unit testing of the new annotation


Thanks,

Kirk Lund

Re: Review Request 39877: GEODE-522: Fix eclipse classpath for generation of IDE project files

[Kirk Lund]

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

Ship it!


Ship It!

- Kirk Lund


On Nov. 2, 2015, 9:38 p.m., Mark Bretl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39877/
> ---
> 
> (Updated Nov. 2, 2015, 9:38 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Kirk Lund, and Dan Smith.
> 
> 
> Bugs: GEODE-522
> https://issues.apache.org/jira/browse/GEODE-522
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-522: Fix eclipse classpath for generation of IDE project files
> 
> 
> Diffs
> -
> 
>   gemfire-web/build.gradle f0de25aa9af036442ce115c82e2b7193504a5236 
> 
> Diff: https://reviews.apache.org/r/39877/diff/
> 
> 
> Testing
> ---
> 
> 'clean eclipse' then import into Spring Tool Suite 3.7.1
> 
> 
> Thanks,
> 
> Mark Bretl
> 
>

Review Request 39877: GEODE-522: Fix eclipse classpath for generation of IDE project files

[Mark Bretl]

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

Review request for geode, Anthony Baker, Kirk Lund, and Dan Smith.


Bugs: GEODE-522
https://issues.apache.org/jira/browse/GEODE-522


Repository: geode


Description
---

GEODE-522: Fix eclipse classpath for generation of IDE project files


Diffs
-

  gemfire-web/build.gradle f0de25aa9af036442ce115c82e2b7193504a5236 

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


Testing
---

'clean eclipse' then import into Spring Tool Suite 3.7.1


Thanks,

Mark Bretl

Re: Apache Geode Clubhouse: Tuesday, November 3

[Matt Ross]

Hey Kirk,

Is there going to be a recording of this for those who can't make it?
Thank you and please let me know.

On Mon, Nov 2, 2015 at 4:05 PM Kirk Lund  wrote:

> Reminder: next Clubhouse is tomorrow (Tues) morning 9AM PST!
>
> Topic is: OQL Querying and Indexing in Geode
>
> Be seeing you,
> Kirk
>
> -- Forwarded message --
> From: Marie Nedich 
> Date: Fri, Oct 23, 2015 at 11:26 AM
> Subject: Apache Geode Clubhouse: Tuesday, November 3
> To: dev@geode.incubator.apache.org, u...@geode.incubator.apache.org
>
>
> Hello, the next Clubhouse is November 3rd!
>
> Title: OQL Querying and Indexing in Geode
> Speaker: Jason Huynh, Apache Geode Committer
> Date: Tuesday, November 3 @ 9AM -10AM PDT
> Abstract: We will discuss how to use Object Query Language (OQL) to create
> queries in Apache Geode (incubating). We will cover query syntax, how the
> query engine executes a query on a partitioned region, what index types are
> supported in Geode, and some miscellaneous querying related topics
> (Undefined objects, Geode specific keywords)
>
> JOIN: https://pivotalcommunity.adobeconnect.com/clubhouse
>
>
> Palo Alto- Tuesday, November 3, 2015 at 9:00:00 AM PST UTC-8 hours
> New York - Tuesday, November 3, 2015 at 12:00:00 Noon EST UTC-5 hours
> Beijing - Wednesday, November 4, 2015 at 1:00:00 AM CST UTC+8 hours
> London - Tuesday, November 3, 2015 at 5:00:00 PM GMT UTC
> Pune - Tuesday, November 3, 2015 at 10:30:00 PM IST UTC+5:30 hours
> Corresponding UTC (GMT)Tuesday, November 3, 2015 at 17:00:00
>
>
> Previous recordings: http://bit.ly/1GZuvcK
>
>
>
> -Marie
>
> --
Matthew Ross | Pivotal Data Engineering | 516-941-7535

Re: Geode Definition of Done (DOD)

[William Markito]

+1

Just one question, what is snapshot build deployed ? Is it the same as
snapshot build successfully completed ?

On Mon, Nov 2, 2015 at 12:44 PM, John Blum  wrote:

> +1
>
> On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
> wrote:
>
> > +1
> > On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
> >
> > > I think we need to settle on a formal Definition of Done (DOD) for
> Apache
> > > Geode. Again, borrowing from Spring Data we could start with what they
> > > define and add to it:
> > >
> > >
> > >- Implemented according to specification in the ticket
> > >- Unit tested
> > >- Integration tested
> > >- Reference documentation updated
> > >- Changelog updated
> > >- Code formatted appropriately
> > >- JavaDoc polished
> > >- Feature branch merged into master [develop?]
> > >- Snapshot build deployed
> > >- Ticket closed
> > >
> > >
> > > https://github.com/spring-projects/spring-data-commons/wiki/DOD
> > >
> > > Any thoughts or feedback?
> > >
> > > -Kirk
> > >
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>



-- 

William Markito Oliveira
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
*

Re: Apache Geode Clubhouse: Tuesday, November 3

[Amy Welch]

Yes, the session will be recorded and posted to the Clubhouse YouTube
channel.

On Mon, Nov 2, 2015 at 1:06 PM, Matt Ross  wrote:

> Hey Kirk,
>
> Is there going to be a recording of this for those who can't make it?
> Thank you and please let me know.
>
> On Mon, Nov 2, 2015 at 4:05 PM Kirk Lund  wrote:
>
>> Reminder: next Clubhouse is tomorrow (Tues) morning 9AM PST!
>>
>> Topic is: OQL Querying and Indexing in Geode
>>
>> Be seeing you,
>> Kirk
>>
>> -- Forwarded message --
>> From: Marie Nedich 
>> Date: Fri, Oct 23, 2015 at 11:26 AM
>> Subject: Apache Geode Clubhouse: Tuesday, November 3
>> To: dev@geode.incubator.apache.org, u...@geode.incubator.apache.org
>>
>>
>> Hello, the next Clubhouse is November 3rd!
>>
>> Title: OQL Querying and Indexing in Geode
>> Speaker: Jason Huynh, Apache Geode Committer
>> Date: Tuesday, November 3 @ 9AM -10AM PDT
>> Abstract: We will discuss how to use Object Query Language (OQL) to
>> create queries in Apache Geode (incubating). We will cover query syntax,
>> how the query engine executes a query on a partitioned region, what index
>> types are supported in Geode, and some miscellaneous querying related
>> topics (Undefined objects, Geode specific keywords)
>>
>> JOIN: https://pivotalcommunity.adobeconnect.com/clubhouse
>>
>>
>> Palo Alto- Tuesday, November 3, 2015 at 9:00:00 AM PST UTC-8 hours
>> New York - Tuesday, November 3, 2015 at 12:00:00 Noon EST UTC-5 hours
>> Beijing - Wednesday, November 4, 2015 at 1:00:00 AM CST UTC+8 hours
>> London - Tuesday, November 3, 2015 at 5:00:00 PM GMT UTC
>> Pune - Tuesday, November 3, 2015 at 10:30:00 PM IST UTC+5:30 hours
>> Corresponding UTC (GMT)Tuesday, November 3, 2015 at 17:00:00
>>
>>
>> Previous recordings: http://bit.ly/1GZuvcK
>>
>>
>>
>> -Marie
>>
>> --
> Matthew Ross | Pivotal Data Engineering | 516-941-7535
>



-- 
Amy Welch
OSS Marketing

Fwd: Apache Geode Clubhouse: Tuesday, November 3

[Kirk Lund]

Reminder: next Clubhouse is tomorrow (Tues) morning 9AM PST!

Topic is: OQL Querying and Indexing in Geode

Be seeing you,
Kirk

-- Forwarded message --
From: Marie Nedich 
Date: Fri, Oct 23, 2015 at 11:26 AM
Subject: Apache Geode Clubhouse: Tuesday, November 3
To: dev@geode.incubator.apache.org, u...@geode.incubator.apache.org


Hello, the next Clubhouse is November 3rd!

Title: OQL Querying and Indexing in Geode
Speaker: Jason Huynh, Apache Geode Committer
Date: Tuesday, November 3 @ 9AM -10AM PDT
Abstract: We will discuss how to use Object Query Language (OQL) to create
queries in Apache Geode (incubating). We will cover query syntax, how the
query engine executes a query on a partitioned region, what index types are
supported in Geode, and some miscellaneous querying related topics
(Undefined objects, Geode specific keywords)

JOIN: https://pivotalcommunity.adobeconnect.com/clubhouse


Palo Alto- Tuesday, November 3, 2015 at 9:00:00 AM PST UTC-8 hours
New York - Tuesday, November 3, 2015 at 12:00:00 Noon EST UTC-5 hours
Beijing - Wednesday, November 4, 2015 at 1:00:00 AM CST UTC+8 hours
London - Tuesday, November 3, 2015 at 5:00:00 PM GMT UTC
Pune - Tuesday, November 3, 2015 at 10:30:00 PM IST UTC+5:30 hours
Corresponding UTC (GMT)Tuesday, November 3, 2015 at 17:00:00


Previous recordings: http://bit.ly/1GZuvcK



-Marie

Re: Geode Definition of Done (DOD)

[John Blum]

+1

On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer 
wrote:

> +1
> On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:
>
> > I think we need to settle on a formal Definition of Done (DOD) for Apache
> > Geode. Again, borrowing from Spring Data we could start with what they
> > define and add to it:
> >
> >
> >- Implemented according to specification in the ticket
> >- Unit tested
> >- Integration tested
> >- Reference documentation updated
> >- Changelog updated
> >- Code formatted appropriately
> >- JavaDoc polished
> >- Feature branch merged into master [develop?]
> >- Snapshot build deployed
> >- Ticket closed
> >
> >
> > https://github.com/spring-projects/spring-data-commons/wiki/DOD
> >
> > Any thoughts or feedback?
> >
> > -Kirk
> >
>



-- 
-John
503-504-8657
john.blum10101 (skype)

Re: JIRA Resolved vs Closed

[John Blum]

+1

To add a bit of clarification on the Resolved vs. Closed status, you can
also think of Closed as the moment the customer/user considers the
issue/enhancement identified in the JIRA as complete and "accepted".  Since
most OSS projects do not have a specific user/customer, then a ticket is
considered closed once released to indicate there were no additional follow
up on the ticket keeping it in an "in-progress" status and holding up the
release.  This is not to say that a ticket cannot be "re-opened" at a later
time if another related problem is found.  However, it usually up to
individual projects to decide whether to re-open the existing ticket or
just file a new one (and link back to the original).

-j


On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund  wrote:

> Is there a standard that ASF follows for when a JIRA ticket changes status
> to Resolved vs Closed?
>
> If not, then I'd like recommend that we follow the process that Spring
> uses:
>
> Ticket changes to Resolved when the fix/implementation is committed or
> merged (to develop in our case). It then moves to Closed when that fix or
> implementation ships in a release. The two different states then have
> meaning and purpose as well as having a clear definition of when a ticket
> should be Resolved vs Closed.
>
> If a bug actually originates on a branch and is then Resolved on that same
> branch before merging anywhere, we could then specify that the ticket
> should be Closed before merging to develop.
>
> Thoughts or feedback?
>
> -Kirk
>



-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Geode Definition of Done (DOD)

[Udo Kohlmeyer]

+1
On 3 Nov 2015 7:14 am, "Kirk Lund"  wrote:

> I think we need to settle on a formal Definition of Done (DOD) for Apache
> Geode. Again, borrowing from Spring Data we could start with what they
> define and add to it:
>
>
>- Implemented according to specification in the ticket
>- Unit tested
>- Integration tested
>- Reference documentation updated
>- Changelog updated
>- Code formatted appropriately
>- JavaDoc polished
>- Feature branch merged into master [develop?]
>- Snapshot build deployed
>- Ticket closed
>
>
> https://github.com/spring-projects/spring-data-commons/wiki/DOD
>
> Any thoughts or feedback?
>
> -Kirk
>

Geode Definition of Done (DOD)

[Kirk Lund]

I think we need to settle on a formal Definition of Done (DOD) for Apache
Geode. Again, borrowing from Spring Data we could start with what they
define and add to it:


   - Implemented according to specification in the ticket
   - Unit tested
   - Integration tested
   - Reference documentation updated
   - Changelog updated
   - Code formatted appropriately
   - JavaDoc polished
   - Feature branch merged into master [develop?]
   - Snapshot build deployed
   - Ticket closed


https://github.com/spring-projects/spring-data-commons/wiki/DOD

Any thoughts or feedback?

-Kirk

JIRA Resolved vs Closed

[Kirk Lund]

Is there a standard that ASF follows for when a JIRA ticket changes status
to Resolved vs Closed?

If not, then I'd like recommend that we follow the process that Spring uses:

Ticket changes to Resolved when the fix/implementation is committed or
merged (to develop in our case). It then moves to Closed when that fix or
implementation ships in a release. The two different states then have
meaning and purpose as well as having a clear definition of when a ticket
should be Resolved vs Closed.

If a bug actually originates on a branch and is then Resolved on that same
branch before merging anywhere, we could then specify that the ticket
should be Closed before merging to develop.

Thoughts or feedback?

-Kirk

Re: Geode Release 1.0.0

[Anilkumar Gingade]

Hi Nitin,

>> can you share any numbers (# of tests still failing or % test passing)?
I will try to see if i can get that number. We are also comparing our
results with older jgroups (Geode develop) test runs, to isolate the issue;
in some cases running the tests multiple times on both develop and Geode-77.

>> Also, any estimate for completion? Are we looking at days, weeks or
months?
The issues we are seeing are harder ones, takes time to reproduce and root
cause; we are making good progress and I believe we are getting closer to
address these issues.

Also, wanted to check with you about Apache Release process...Do we have
any write-up/doc on the release activities...

Is GEODE-25 needs to be addressed for Release?

Thanks,
-Anil.





On Mon, Nov 2, 2015 at 9:29 AM, Kirk Lund  wrote:

> Nitin,
>
> The JIRA tickets for CI failures do not have a common parent JIRA, but
> here's a query to see what's still open:
>
> project = GEODE AND status in (Open, "In Progress", Reopened) AND labels =
> CI
>
> There are currently 57 open CI tickets. We are not officially continuing
> the Squashathon but contributors need to continue to work on fixing these
> tests. Discovery rate of new buggy DistributedTests is down to a few a day
> and we've improved reliability such that we're up to at least 33% green
> builds for any testing target that includes DistributedTests. My rough
> estimate is 3 more weeks of dedicated work by 12 or more developers to
> bring it up to very consistent green builds.
>
> Fixing the Client/Server DistributedTests is an open problem because the
> team that would focus on those bugs is busy working on JGroups.
>
> -Kirk
>
>
> On Thu, Oct 29, 2015 at 11:23 PM, Nitin Lamba  wrote:
>
> > Thanks Anil for the update! Seems JGroups is progressing well. Out of
> > curiosity, can you share any numbers (# of tests still failing or % test
> > passing)?
> >
> > Also, any estimate for completion? Are we looking at days, weeks or
> months?
> >
> > GEODE-18 is also getting close. That only leaves tests to be resolved
> > before we can cut a release.
> >
> > Kirk: any latest update from the Bug Squashathon from last week? Is there
> > a parent JIRA that we can track on the Release page?
> >
> > -Nitin
> >
> > 
> > From: Anilkumar Gingade 
> > Sent: Thursday, October 29, 2015 10:54 PM
> > To: dev@geode.incubator.apache.org
> > Subject: Re: Geode Release 1.0.0
> >
> > Status update on Geode-77:
> >
> > We have made a great progress from where we were last week to this
> > week...Last weekend, we started one more round of test runs (GemFire
> > products HA test suites); from this run, we are seeing test failure count
> > coming down significantly; and we are not seeing failures at the
> test-suite
> > level (set of tests covering particular feature), instead we are seeing
> > failures at individual test-case level...
> >
> > From the analysis we are seeing issues relating to:
> > - Members not getting kicked out when they are supposed.
> > - Members unexpectedly getting disconnected during HA.
> > - Cache server spends time processing membership views after it is asked
> to
> > stop.
> > - Data inconsistency and performance issues with udp messaging.
> > - Data inconsistency issue with wan and transaction.
> > - Issues with startup during HA.
> > - Issue with stopping process during the end of a HA test.
> > - Issue with client/server transaction with HA.
> > - Functions not getting directed to expected nodes.
> >
> > Team is working aggressively to address these issues...
> >
> > -Anil.
> >
> >
> >
> >
> > On Tue, Oct 20, 2015 at 5:54 PM, Anilkumar Gingade 
> > wrote:
> >
> > > Update on GEODE-77:
> > >
> > > As part of GEODE-77 we started replacing the old JGroups code that had
> a
> > > LGPL license (incompatible with Apache) with the new version of
> JGroups.
> > >
> > > Proposal and the work regarding this can be found at:
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Replacing+JGroups+2.2.9
> > > (JGroups section).
> > > The work is done on feature branch: "feature/GEODE-77"
> > >
> > > We have done a great progress in adopting the new JGroups version; the
> > > development work to provide similar stability and features as with
> > > commercial GemFire product (with old JGroups) has been completed.
> > >
> > > Currently we are in hardening phase, trying to get the tests
> successfully
> > > running and address any issues found:
> > >
> > > The unit tests are passing and we have only one failure, that is also
> > seen
> > > in development branch.
> > >
> > > In order to shake out any additional real-world problem; we are running
> > > changes through GemFire products HA test suites...
> > >
> > > At high level we are seeing issues with:
> > >
> > > - Members unfairly getting kicked out from the cluster.
> > >   Note: We are addressing this by adding tcp/ip connection check
> > mechanism.
> > > - We are sometimes not fast enough to detect crashes.
> > 

[GitHub] incubator-geode pull request: adding RHEL/CENTOS init scripts for ...

[zhansen-pivotal]

Github user zhansen-pivotal closed the pull request at:

https://github.com/apache/incubator-geode/pull/27


---
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: Geode Release 1.0.0

[Kirk Lund]

Nitin,

The JIRA tickets for CI failures do not have a common parent JIRA, but
here's a query to see what's still open:

project = GEODE AND status in (Open, "In Progress", Reopened) AND labels =
CI

There are currently 57 open CI tickets. We are not officially continuing
the Squashathon but contributors need to continue to work on fixing these
tests. Discovery rate of new buggy DistributedTests is down to a few a day
and we've improved reliability such that we're up to at least 33% green
builds for any testing target that includes DistributedTests. My rough
estimate is 3 more weeks of dedicated work by 12 or more developers to
bring it up to very consistent green builds.

Fixing the Client/Server DistributedTests is an open problem because the
team that would focus on those bugs is busy working on JGroups.

-Kirk


On Thu, Oct 29, 2015 at 11:23 PM, Nitin Lamba  wrote:

> Thanks Anil for the update! Seems JGroups is progressing well. Out of
> curiosity, can you share any numbers (# of tests still failing or % test
> passing)?
>
> Also, any estimate for completion? Are we looking at days, weeks or months?
>
> GEODE-18 is also getting close. That only leaves tests to be resolved
> before we can cut a release.
>
> Kirk: any latest update from the Bug Squashathon from last week? Is there
> a parent JIRA that we can track on the Release page?
>
> -Nitin
>
> 
> From: Anilkumar Gingade 
> Sent: Thursday, October 29, 2015 10:54 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Geode Release 1.0.0
>
> Status update on Geode-77:
>
> We have made a great progress from where we were last week to this
> week...Last weekend, we started one more round of test runs (GemFire
> products HA test suites); from this run, we are seeing test failure count
> coming down significantly; and we are not seeing failures at the test-suite
> level (set of tests covering particular feature), instead we are seeing
> failures at individual test-case level...
>
> From the analysis we are seeing issues relating to:
> - Members not getting kicked out when they are supposed.
> - Members unexpectedly getting disconnected during HA.
> - Cache server spends time processing membership views after it is asked to
> stop.
> - Data inconsistency and performance issues with udp messaging.
> - Data inconsistency issue with wan and transaction.
> - Issues with startup during HA.
> - Issue with stopping process during the end of a HA test.
> - Issue with client/server transaction with HA.
> - Functions not getting directed to expected nodes.
>
> Team is working aggressively to address these issues...
>
> -Anil.
>
>
>
>
> On Tue, Oct 20, 2015 at 5:54 PM, Anilkumar Gingade 
> wrote:
>
> > Update on GEODE-77:
> >
> > As part of GEODE-77 we started replacing the old JGroups code that had a
> > LGPL license (incompatible with Apache) with the new version of JGroups.
> >
> > Proposal and the work regarding this can be found at:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Replacing+JGroups+2.2.9
> > (JGroups section).
> > The work is done on feature branch: "feature/GEODE-77"
> >
> > We have done a great progress in adopting the new JGroups version; the
> > development work to provide similar stability and features as with
> > commercial GemFire product (with old JGroups) has been completed.
> >
> > Currently we are in hardening phase, trying to get the tests successfully
> > running and address any issues found:
> >
> > The unit tests are passing and we have only one failure, that is also
> seen
> > in development branch.
> >
> > In order to shake out any additional real-world problem; we are running
> > changes through GemFire products HA test suites...
> >
> > At high level we are seeing issues with:
> >
> > - Members unfairly getting kicked out from the cluster.
> >   Note: We are addressing this by adding tcp/ip connection check
> mechanism.
> > - We are sometimes not fast enough to detect crashes.
> > - We are having serialization and deserialization problems handling old
> > GemFire clients and in Transactions.
> > - Seeing issues with UDP messaging.
> >
> > We still have undiagnosed failures that we are looking into…I will keep
> > this thread updated as we analyze the test runs and any progress we make
> in
> > addressing the issues.
> >
> > Let me know if you have any questions.
> >
> > Thanks,
> > -Anil.
> >
> >
> >
> > On Fri, Oct 16, 2015 at 3:47 PM, Nitin Lamba  wrote:
> >
> >> Just a weekly check-in on the alpha release activities. Are there any
> >> updates on:
> >> - GEODE-77 [Bruce]: Any ETA established for this?
> >> - GEODE-18 [Anthony] Any update from the patch that was submitted?
> >>
> >> Thanks,
> >> Nitin
> >> 
> >> From: Anthony Baker 
> >> Sent: Friday, October 9, 2015 2:08 PM
> >> To: dev@geode.incubator.apache.org
> >> Subject: Re: Geode Release 1.0.0
> >>
> >> Per gitflow, we establish a release-X branch for stabilization from
> >> devel