Re: Draft of August 2020 Geode report to the board
Thanks, Anthony. Here is Draft 2 of the August board report. Corrections and comments by Monday at noon please. ## Description: The mission of Apache Geode is the creation and maintenance of software related to a data management platform that provides real-time, consistent access to data-intensive applications throughout widely distributed cloud architectures. ## Issues: There are no issues requiring board attention. - 309 issues opened in JIRA, past quarter (-3% decrease) - 244 issues closed in JIRA, past quarter (1% increase) ## Membership Data: Apache Geode was founded 2016-11-15 (4 years ago) There are currently 109 committers and 54 PMC members in this project. Community changes, past quarter: - No new PMC members. Last addition was Alexander Murmann on 2020-03-26. - No new committers. Last addition was Mario Kevo on 2020-03-23. ## Project Activity: We're actively working on the version 1.13 release, with many discussions over code inclusions that delay the release, but provide a higher quality product. There is significant discussion and activity surrounding: - WAN Configuration for an Ingress Proxy - Avoiding the queuing of dropped events by the primary gateway sender when the gateway sender is stopped - Geode Redis API improvements - Modularization / classloader isolation - Support for an operation that clears a partitioned region ## Community Health: The Apache Geode dev mailing list had a 26% decrease in traffic, while the issues mailing list experienced a 32% increase in traffic in Q2. We are planning a Geode content track for ApacheCon @Home. We have two days of content based on submissions from the community. May-July brought 7 new blog posts: - "Spring Security & Geode" by community member Juan José Ramos at https://medium.com/@jujoramos/spring-security-geode-4670faff47a0 - "Logging Apache Geode GatewaySender Queue Events" by community member Barry Oglesby at https://medium.com/ @boglesby_2508/logging-apache-geode-gatewaysender-queue-events-e7e19937a542 - "Verifying Apache Geode Region Consistency in Different Distributed Systems" by community member Barry Oglesby at https://medium.com/@boglesby_2508/verifying-ap ache-geode-region-consistency-in-different-distributed-systems-e15d6edfe15d - "Geode Write-Behind Event Handling with Spring JPA" by community member Juan José Ramos at https://medium.co m/@jujoramos/geode-write-behind-event-handling-with-spring-jpa-a54f17e19709 - "Calculating the Size of an Apache Geode Region" by community member Barry Oglesby at https:// medium.com/swlh/calculating-the-size-of-an-apache-geode-region-5ffb3b141464 - "Improving the Performance of Apache Geode Persistence Recovery" by community member Jianxia Chen at https://medium.com/@luckycjx /improving-the-performance-of-apache-geode-persistence-recovery-af08918d2ef - "Threads Used in Apache Geode Function Execution" by community member Barry Oglesby at https://m edium.com/swlh/threads-used-in-apache-geode-function-execution-9dd707cf227c > >
Re: [PROPOSAL] Postpone Geode 1.14
Hi Michael, lack of replies may be simply due to not having shipped 1.13 yet.
Once it's in the rearview mirror, folks may be more in the frame of mind to
look back at it, perhaps as part of the already-proposed discussion ("Once we
have shipped 1.13, we should discuss when we want to cut the 1.14").
Traditionally Geode uses the [DISCUSS] email thread format to accommodate our
worldwide developer community. Looking forward to hearing your voice (and
hopefully many others) soon.
On 8/7/20, 12:00 PM, "Michael Oleske" wrote:
I'm going to take the lack of replies as there are no plans for a
retrospective on this. If there is interest in doing this in the future, I'd
be happy to facilitate the discussion.
-michael
From: Mark Hanson
Sent: Monday, August 3, 2020 09:59
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1 to Michael's suggestion.
On 7/31/20, 5:38 PM, "Michael Oleske" wrote:
Is there plans as a community to do a postmortem or retrospective
around why the release is taking so long? If there is an understanding of
events that occurred to cause the long delay of Geode 1.13 to be released, that
would help inform decisions if processes should change or if the release
cadence should change (or both!)
-michael
From: Xiaojian Zhou
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
On 7/29/20, 1:35 PM, "Mark Bretl" wrote:
+1
Should we need to drop a line to user@geode or is communicating on
this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior
wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann"
wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to
hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to
cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important
information
> for
> that conversation. Thus we cannot have that conversation
before then.
>
>
Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode repo
Voting results: +1: 7 0: 0 -1: 0 It's past the announced deadline and the voting is successful. All proposed tags have now been deleted (except sga2-core). Your existing checkouts will continue to show these tags, even after a pull, unless you A) resync from github or B) delete them manually. A) To resync from github (warning: this will also delete any local tags you haven't pushed): git fetch origin --prune --prune-tags B) If you need to preserve other local tags, for each of the 89 tags listed below do: git tag --delete On 8/3/20, 2:19 PM, "Raymond Ingles" wrote: +1 On 7/30/20, 3:21 AM, "Owen Nichols" wrote: Tags in the rel/ namespace should be created by the Geode release manager as part of an official Geode release only, yet we seem to have some extra ones somehow. Further, I don't see any value in keeping RC tags forever long after the release is final. Please vote +1 in favor of trimming the current list of 110 tags down to 20 to make it nice and easy for newcomers (as well as the rest of us) to find and checkout a specific version of Geode; otherwise vote -1. If the majority vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and delete the 90 unnecessary tags as detailed below. I propose to KEEP only the following tags, corresponding to official Geode releases: rel/v1.12.0 rel/v1.11.0 rel/v1.10.0 rel/v1.9.2 rel/v1.9.1 rel/v1.9.0 rel/v1.8.0 rel/v1.7.0 rel/v1.6.0 rel/v1.5.0 rel/v1.4.0 rel/v1.3.0 rel/v1.2.1 rel/v1.2.0 rel/v1.1.1 rel/v1.1.0 rel/v1.0.0-incubating rel/v1.0.0-incubating.M3 rel/v1.0.0-incubating.M2 rel/v1.0.0-incubating.M1 I propose a one-time cleanup to DELETE all other tags, specifically: develop/highwater modules-pre-merge rel/v1.0.0-incubating.M1.RC1 rel/v1.0.0-incubating.M1.RC2 rel/v1.0.0-incubating.M2.RC1 rel/v1.0.0-incubating.M2.RC2 rel/v1.0.0-incubating.M3.RC1 rel/v1.0.0-incubating.M3.RC2 rel/v1.0.0-incubating.M3.RC3 rel/v1.0.0-incubating.M3.RC4 rel/v1.0.0-incubating.M3.RC5 rel/v1.0.0-incubating.M3.RC6 rel/v1.0.0-incubating.M3.RC7 rel/v1.0.0-incubating.RC1 rel/v1.0.0-incubating.RC2 rel/v1.1.0.RC1 rel/v1.1.0.RC2 rel/v1.1.0manualrev-2017-02-16 rel/v1.1.0manualrev-2017-10-19 rel/v1.1.1.RC1 rel/v1.1.1.RC2 rel/v1.10.0.1 rel/v1.10.0.1.RC1 rel/v1.10.0.2 rel/v1.10.0.RC1 rel/v1.10.0.RC2 rel/v1.11.0.1 rel/v1.11.0.2 rel/v1.11.0.23755 rel/v1.11.0.23755_2 rel/v1.11.0.23755_3 rel/v1.11.0.3 rel/v1.11.0.4 rel/v1.11.0.5 rel/v1.11.0.6 rel/v1.11.0.7 rel/v1.11.0.7565 rel/v1.11.0.8 rel/v1.11.0.RC1 rel/v1.11.0.RC2 rel/v1.11.0.RC3 rel/v1.11.0.RC4 rel/v1.12.0.1 rel/v1.12.0.1234 rel/v1.12.0.2 rel/v1.12.0.23755 rel/v1.12.0.3 rel/v1.12.0.4 rel/v1.12.0.5 rel/v1.12.0.6 rel/v1.12.0.RC1 rel/v1.12.0.RC2 rel/v1.12.0.RC3 rel/v1.12.0.RC4 rel/v1.14.0.23755 rel/v1.2.0.RC1 rel/v1.2.0.RC2 rel/v1.2.1.RC1 rel/v1.2.1.RC2 rel/v1.2.1.RC3 rel/v1.2.1.RC4 rel/v1.2.1manualrev-2017-10-19 rel/v1.3.0.RC1 rel/v1.3.0.RC2 rel/v1.3.0.RC3 rel/v1.3.0.RC4 rel/v1.4.0.RC1 rel/v1.4.0.RC2 rel/v1.5.0.RC1 rel/v1.5.0.RC2 rel/v1.6.0.RC1 rel/v1.7.0.RC1 rel/v1.7.0.RC2 rel/v1.8.0.RC1 rel/v1.8.0.RC2 rel/v1.9.0.1 rel/v1.9.0.1.RC1 rel/v1.9.0.2 rel/v1.9.0.RC1 rel/v1.9.0.RC2 rel/v1.9.0.RC3 rel/v1.9.0.RC4 rel/v1.9.1-nordix rel/v1.9.1.RC1 rel/v1.9.1.RC2 rel/v1.9.1.RC3 rel/v1.9.2.RC1 v1.1.0manualrev-2017-10-19 v9.0.0-beta.1
Re: Draft of August 2020 Geode report to the board
Nice! I would also call out a significant increase in (awesome) community blog posts: https://medium.com/p/threads-used-in-apache-geode-function-execution-9dd707cf227c?source=email-9fb0d2d72e25--writer.postDistributed=bfb9703d4399c681a447389c689094af https://medium.com/@luckycjx/improving-the-performance-of-apache-geode-persistence-recovery-af08918d2ef?source=friends_link=850d19f929b7c54275a18a2ad43ba6d7 https://medium.com/@boglesby_2508/calculating-the-size-of-an-apache-geode-region-5ffb3b141464 https://medium.com/@jujoramos/geode-write-behind-event-handling-with-spring-jpa-a54f17e19709 https://medium.com/@boglesby_2508/verifying-apache-geode-region-consistency-in-different-distributed-systems-e15d6edfe15d https://medium.com/@boglesby_2508/logging-apache-geode-gatewaysender-queue-events-e7e19937a542 https://medium.com/@jujoramos/spring-security-geode-4670faff47a0 Perhaps also highlight that several RFC’s are seeing significant discussion and/or activity including: - WAN Configuration for an Ingress Proxy - Avoid the queuing of dropped events by the primary gateway sender when the gateway sender is stopped - Geode Redis API Improvements, - Modularization / Classloader Isolation - Support for clear operation on partitioned region Anthony > On Aug 7, 2020, at 11:00 AM, Karen Miller wrote: > > Here's a first draft of a board report. I'd like to include some of the > project's many blog posts (any new videos? did anyone give a Geode talk at > a workshop or conference?) in our Community Health section. Please send me > a link and hopefully an approximate date when the blog was posted. > > Please approve or get me additions/corrections before Monday August 10 at > noon Pacific time, so I can file our report on time. > Thanks. Karen > > ## Description: > The mission of Apache Geode is the creation and maintenance of software > related > to a data management platform that provides real-time, consistent access to > data-intensive applications throughout widely distributed cloud > architectures. > > ## Issues: > There are no issues requiring board attention. > - 309 issues opened in JIRA, past quarter (-3% decrease) > - 244 issues closed in JIRA, past quarter (1% increase) > > ## Membership Data: > Apache Geode was founded 2016-11-15 (4 years ago) > There are currently 109 committers and 54 PMC members in this project. > > Community changes, past quarter: > - No new PMC members. Last addition was Alexander Murmann on 2020-03-26. > - No new committers. Last addition was Mario Kevo on 2020-03-23. > > ## Project Activity: > We're actively working on the version 1.13 release, with many discussions > over code inclusions that delay the release, but provide a higher quality > product. > > ## Community Health: > The Apache Geode dev mailing list had a 26% decrease in traffic, while the > issues mailing list experienced a 32% increase in traffic in Q2. > > We are planning a Geode content track for ApacheCon @Home. We have two days > of content based on submissions from the community.
Re: [PROPOSAL] Postpone Geode 1.14
I'm going to take the lack of replies as there are no plans for a retrospective on this. If there is interest in doing this in the future, I'd be happy to facilitate the discussion. -michael From: Mark Hanson Sent: Monday, August 3, 2020 09:59 To: dev@geode.apache.org Subject: Re: [PROPOSAL] Postpone Geode 1.14 +1 to Michael's suggestion. On 7/31/20, 5:38 PM, "Michael Oleske" wrote: Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released, that would help inform decisions if processes should change or if the release cadence should change (or both!) -michael From: Xiaojian Zhou Sent: Thursday, July 30, 2020 13:47 To: dev@geode.apache.org Subject: Re: [PROPOSAL] Postpone Geode 1.14 +1 On 7/29/20, 1:35 PM, "Mark Bretl" wrote: +1 Should we need to drop a line to user@geode or is communicating on this list enough once decided? --Mark On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior wrote: > +1 > > On 2020-07-28, 7:34 PM, "Alexander Murmann" wrote: > > Hi all, > > As mentioned on the previous discuss thread, I propose to hold off > cutting > 1.14 until we have shipped 1.13. > > Once we have shipped 1.13, we should discuss when we want to cut the > 1.14 > release. The actual ship date for Geode 1.13 is important information > for > that conversation. Thus we cannot have that conversation before then. > >
Re: [PROPOSAL] backport GEODE-8394 to support/1.13
Plenty of approvals. Go ahead and port, Anil. Thanks! On Fri, Aug 7, 2020 at 11:08 AM Owen Nichols wrote: > +1 and please bring to support/1.12 as well > > On 8/7/20, 10:49 AM, "Jianxia Chen" wrote: > > +1 > > On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade > > wrote: > > > This causes a large object to be partially (corrupt data) stored in > cache > > instead of throwing an exception. > > > > > >
Re: [PROPOSAL] backport GEODE-8394 to support/1.13
+1 and please bring to support/1.12 as well On 8/7/20, 10:49 AM, "Jianxia Chen" wrote: +1 On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade wrote: > This causes a large object to be partially (corrupt data) stored in cache > instead of throwing an exception. > >
Draft of August 2020 Geode report to the board
Here's a first draft of a board report. I'd like to include some of the project's many blog posts (any new videos? did anyone give a Geode talk at a workshop or conference?) in our Community Health section. Please send me a link and hopefully an approximate date when the blog was posted. Please approve or get me additions/corrections before Monday August 10 at noon Pacific time, so I can file our report on time. Thanks. Karen ## Description: The mission of Apache Geode is the creation and maintenance of software related to a data management platform that provides real-time, consistent access to data-intensive applications throughout widely distributed cloud architectures. ## Issues: There are no issues requiring board attention. - 309 issues opened in JIRA, past quarter (-3% decrease) - 244 issues closed in JIRA, past quarter (1% increase) ## Membership Data: Apache Geode was founded 2016-11-15 (4 years ago) There are currently 109 committers and 54 PMC members in this project. Community changes, past quarter: - No new PMC members. Last addition was Alexander Murmann on 2020-03-26. - No new committers. Last addition was Mario Kevo on 2020-03-23. ## Project Activity: We're actively working on the version 1.13 release, with many discussions over code inclusions that delay the release, but provide a higher quality product. ## Community Health: The Apache Geode dev mailing list had a 26% decrease in traffic, while the issues mailing list experienced a 32% increase in traffic in Q2. We are planning a Geode content track for ApacheCon @Home. We have two days of content based on submissions from the community.
Re: [PROPOSAL] backport GEODE-8394 to support/1.13
+1 On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade wrote: > This causes a large object to be partially (corrupt data) stored in cache > instead of throwing an exception. > >
Re: [PROPOSAL] backport GEODE-8394 to support/1.13
Super +1 From: Anilkumar Gingade Sent: Friday, August 7, 2020 10:34 AM To: dev@geode.apache.org Subject: [PROPOSAL] backport GEODE-8394 to support/1.13 This causes a large object to be partially (corrupt data) stored in cache instead of throwing an exception.
Re: [PROPOSAL] backport GEODE-8394 to support/1.13
+1 From: Anilkumar Gingade Sent: Friday, August 7, 2020 10:34 AM To: dev@geode.apache.org Subject: [PROPOSAL] backport GEODE-8394 to support/1.13 This causes a large object to be partially (corrupt data) stored in cache instead of throwing an exception.
[PROPOSAL] backport GEODE-8394 to support/1.13
This causes a large object to be partially (corrupt data) stored in cache instead of throwing an exception.
