The 1.11.0 branch we be cut on November 4th, 2019.

[Mark Hanson]

Please ensure that your changes are in November 3rd, 2019 at the latest. I will 
pick the SHA of the first successful build on November 4th, 2019.


If you realize your change will not make the cut and think it should, please 
let me know.


Thanks,
Mark Hanson

Re: What tomcat8 is Geode using?

[Dan Smith]

To be clear, we are not actually shipping tomcat with geode. But we do
compile and test our session replication modules against multiple versions
of tomcat. We test against all the versions listed in that
DependencyContraints.groovy file:

deps.put("tomcat6.version", "6.0.37")
deps.put("tomcat7.version", "7.0.90")
deps.put("tomcat8.version", "8.5.34")
deps.put("tomcat9.version", "9.0.12")

I think all of the bits we test against come from maven, but some unit
tests may just use a tomcat jar, vs. some integration tests that unpack a
full tomcat install.
-Dan


On Mon, Oct 28, 2019 at 1:20 PM Robert Houghton 
wrote:

> Hi Kirk,
>
> Looking at extensions/geode-modules-tomcat8, that version (8.5.34) is what
> we are compiling and testing against in this module.
>
> On Thu, Oct 24, 2019 at 10:55 AM Kirk Lund  wrote:
>
> > What actual artifacts does this refer to in DependencyConstraints.groovy?
> >
> > deps.put("tomcat8.version", "8.5.34")
> >
> > Does this mean we are using
> >
> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina/8.5.34
> > or some download?
> >
>

Re: [Proposal] Cut 1.11.0 branch on November 4th, 2019.

[Alexander Murmann]

 This matches what we discussed on the previous thread!

Thanks of stepping up!

On Mon, Oct 28, 2019 at 2:33 PM Mark Hanson  wrote:

> Hi All,
>
> Looks like I won the contest to be release manager by default, so let's
> get started….
>
> I think we should cut the branch on November 4th, 2019.  Assuming that is
> agreed to, I would pick the most stable build during that day.
>
> Please get back to me if you have any concerns.
>
> Thanks,
> Mark

Re: [VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

[Alexander Murmann]

Owen, could you remind me which step requires PMC creds? I don't recall
needing them when I managed a release earlier this year.

On Mon, Oct 28, 2019 at 2:10 PM Owen Nichols  wrote:

> Fantastic, Mark!
>
> Please having a look at
> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode <
> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode>
> and if you have any questions, there are now quite a few past release
> managers on the dev list who should be able to answer any questions you
> might have!
>
> Please note that there is one step in the release process that requires
> PMC credentials.  Mark, it appears <
> https://projects.apache.org/committee.html?geode> that you are a
> committer but not a Geode PMC member.  Would someone who is on the PMC like
> to volunteer to assist Mark for that one critical step?
>
> > On Oct 28, 2019, at 2:00 PM, Mark Hanson  wrote:
> >
> > Hi All,
> >
> > Since we need a release manager for 1.11 and no one has volunteered,
> yet. I thought I would volunteer.
> >
> > Thanks,
> > Mark
>
>

[Proposal] Cut 1.11.0 branch on November 4th, 2019.

[Mark Hanson]

Hi All,

Looks like I won the contest to be release manager by default, so let's get 
started….

I think we should cut the branch on November 4th, 2019.  Assuming that is 
agreed to, I would pick the most stable build during that day.

Please get back to me if you have any concerns.

Thanks,
Mark

Re: [VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

[Owen Nichols]

Fantastic, Mark!

Please having a look at 
https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode 
 and 
if you have any questions, there are now quite a few past release managers on 
the dev list who should be able to answer any questions you might have!

Please note that there is one step in the release process that requires PMC 
credentials.  Mark, it appears 
 that you are a committer but 
not a Geode PMC member.  Would someone who is on the PMC like to volunteer to 
assist Mark for that one critical step?

> On Oct 28, 2019, at 2:00 PM, Mark Hanson  wrote:
> 
> Hi All,
> 
> Since we need a release manager for 1.11 and no one has volunteered, yet. I 
> thought I would volunteer.
> 
> Thanks,
> Mark

Re: [VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

[Dave Barnes]

Mark - I'll help out with docs -- updating the website, etc.

On Mon, Oct 28, 2019 at 2:00 PM Mark Hanson  wrote:

> Hi All,
>
> Since we need a release manager for 1.11 and no one has volunteered, yet.
> I thought I would volunteer.
>
> Thanks,
> Mark

[VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

[Mark Hanson]

Hi All,

Since we need a release manager for 1.11 and no one has volunteered, yet. I 
thought I would volunteer.

Thanks,
Mark

Re: Deprecate SystemFailure Class

[Robert Houghton]

+1.

On Mon, Oct 28, 2019 at 12:11 PM Bill Burcham 
wrote:

> The SystemFailure class is a clearing house for detecting and attempting to
> mitigate SystemFailure exceptions e.g. VirtualMachineError and
> OutOfMemoryError.
>
> This class should not exist. SystemFailure exceptions should be allowed to
> percolate up and cause the JVM to terminate as soon as possible with an
> informative message in the log, if possible.
>
> Here is what the JVM spec has to say [1]:
>
> "A Java Virtual Machine implementation throws an object that is an instance
> of a subclass of the class VirtualMethodError (sic) when an internal error
> or resource limitation prevents it from implementing the semantics
> described in this chapter. This specification cannot predict where internal
> errors or resource limitations may be encountered and does not mandate
> precisely when they can be reported."
>
> There's a typo in the spec there: it says "VirtualMethodError" when it
> means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
> apply after you've encountered a VirtualMachineError. As a result, there is
> no reason to believe that subsequent processing will make things better
> (than exiting immediately).
>
> The SystemFailure class should be deprecated so no new dependencies to it
> are added. Existing dependencies on it, should be eliminated over time.
>
> Do you have any objections to deprecating the class and beginning
> elimination of usage of it within Geode?
>
> Regards,
> Bill
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> [2] oh and here's a ticket
> https://issues.apache.org/jira/browse/GEODE-7369
>

Re: What tomcat8 is Geode using?

[Robert Houghton]

Hi Kirk,

Looking at extensions/geode-modules-tomcat8, that version (8.5.34) is what
we are compiling and testing against in this module.

On Thu, Oct 24, 2019 at 10:55 AM Kirk Lund  wrote:

> What actual artifacts does this refer to in DependencyConstraints.groovy?
>
> deps.put("tomcat8.version", "8.5.34")
>
> Does this mean we are using
> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina/8.5.34
> or some download?
>

Re: [REQUEST] Squash merge please

[Jacob Barrett]

+1


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

Deprecate SystemFailure Class

[Bill Burcham]

The SystemFailure class is a clearing house for detecting and attempting to
mitigate SystemFailure exceptions e.g. VirtualMachineError and
OutOfMemoryError.

This class should not exist. SystemFailure exceptions should be allowed to
percolate up and cause the JVM to terminate as soon as possible with an
informative message in the log, if possible.

Here is what the JVM spec has to say [1]:

"A Java Virtual Machine implementation throws an object that is an instance
of a subclass of the class VirtualMethodError (sic) when an internal error
or resource limitation prevents it from implementing the semantics
described in this chapter. This specification cannot predict where internal
errors or resource limitations may be encountered and does not mandate
precisely when they can be reported."

There's a typo in the spec there: it says "VirtualMethodError" when it
means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
apply after you've encountered a VirtualMachineError. As a result, there is
no reason to believe that subsequent processing will make things better
(than exiting immediately).

The SystemFailure class should be deprecated so no new dependencies to it
are added. Existing dependencies on it, should be eliminated over time.

Do you have any objections to deprecating the class and beginning
elimination of usage of it within Geode?

Regards,
Bill

[1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
[2] oh and here's a ticket https://issues.apache.org/jira/browse/GEODE-7369

Re: [DISCUSS] Geode Redis Adapter

[Jacob Barrett]

I would just leave it where it is and make sure we document the issues you have 
identified in JIRA. This gives others the opportunity to make it better.

-Jake


> On Oct 23, 2019, at 10:10 AM, Patrick Johnson  wrote:
> 
> I noticed that Geodes Redis Adapter needs some work, but doesn't seem to
> have gotten much attention recently. In its current state, it is confusing
> for users looking to run their Redis clients against Geode. What do you
> think about moving it to a branch until we make it better?

Review for #4204

[Alberto Gomez]

Hi,

Could I ask for a review on https://github.com/apache/geode/pull/4204?

This PR is about GEODE-7157: 
(https://jira.apache.org/jira/browse/GEODE-7157).

Thanks,

/Alberto G.

[ANNOUNCE] Apache Geode 1.9.2

[Jens Deppe]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.9.2.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.9.2 contains a number of improvements and bug fixes.


   - Added the ability to specify that when an asynchronous event queue
   (AEQ) first starts, event processing should be paused. A `resume` command
   is provided to start event processing at the desired time. Three gfsh
   commands were added or modified to support this capability: "create
   async-event-queue --pause-event-processing", "alter async-event-queue
   --pause-event-processing", and "resume async-event-queue-dispatcher". See
   the gfsh command reference in the Geode User Guide for details.
   - Publish war artifacts for geode-web , geode-web-api and
   geode-web-management to Maven Central.
   - Fix compatibility with launching geode-web (admin REST API) when
   Spring 5.x jars are on the classpath.


For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/19/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Jens Deppe on behalf of the Apache Geode team

[DISCUSS] review process documentation

[Owen Nichols]

Below is everything I could find addressing our current process around making 
and reviewing commits.  If you’re a newer contributor, what topics are missing 
or unclear?  If you’ve been a committer for a long time, does what’s in the 
wiki align with your understanding?  Are there unwritten norms that might not 
be obvious to a new contributor?  Thanks for taking a few minutes to review.


VOTEs:

June 2017: Require committers to use GitHub PR’s 


DISCUSSions: 

Oct 2019: Blocking merge button in PR 

Oct 2019: No-one is following our commit message formatting 

Jun 2019: Adopting a coding standard 

Sep 2018: Commit message formatting 

Sep 2018: Test code style (particularly logging) 

Sep 2018: Should we evaluate commit messages as part of PR review? 

Feb 2017: JIRA guidelines 


WIKI pages:

Aug 2018: Criteria for Code Submissions 

Sep 2017: Code contributions 

Feb 2017: JIRA Guidelines 


PR template:

Mar 2019: PULL_REQUEST_TEMPLATE.md