Let's reopen the vote! On Wed, Aug 28, 2019 at 1:49 PM Kirk Lund <kl...@apache.org> wrote:
> Do folks actually want a 1.9.1 release? > > On Wed, Aug 28, 2019 at 1:38 PM Owen Nichols <onich...@pivotal.io> wrote: > >> The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this >> thread to continue the discussion. >> >> Is there still a need for a 1.9 patch release (especially given that >> 1.10.0.RC1 is expected later this week)? >> >> If so, perhaps we should back up a step or two and first: >> 1) come to rough consensus that 1.9.1 is still desired (and what should >> be in it) >> 2) ensure that we have Geode PMC support for this release >> 3) go through the formal process of voting each cherry-pick in the patch >> release >> >> This could result in a recommendation to re-vote on RC1, a recommendation >> to produce a new RC2, a recommendation to pull the plug (or no >> recommendation). >> >> As a failsafe, I hereby invoke lazy consensus: In the event that no >> explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep >> 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging >> repo and remove 1.9.1 from the release notes wiki. >> >> -Owen >> >> >> > On Aug 18, 2019, at 7:52 AM, Anthony Baker <aba...@pivotal.io> wrote: >> > >> > Yep. Get a release manager, identify and cherry pick all the changes, >> then do the release. >> > >> > Anthony >> > >> >> On Aug 16, 2019, at 4:21 PM, Kirk Lund <kl...@apache.org> wrote: >> >> >> >> Does anyone know what the next step is? Do we need a release manager to >> >> proceed? >> >> >> >>> On Tue, Aug 13, 2019 at 1:57 PM John Blum <jb...@pivotal.io> wrote: >> >>> >> >>> Sorry, corrections below... >> >>> >> >>>> On Tue, Aug 13, 2019 at 1:54 PM John Blum <jb...@pivotal.io> wrote: >> >>>> >> >>>> Stated slightly a different way... >> >>>> >> >>>> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, >> then >> >>>> it would *defy* the dependency on Apache Geode pulled in by SDG >> Moore/2.2 >> >>>> (which is and can only be Geode 1.9 *at this point*) for which SBDG >> is >> >>>> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 >> and >> >>>> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well. As >> such, >> >>>> the stars would not align and it would cause issues (or unexpected >> >>>> surprises, possibly conflicts) for users of Spring Boot when also >> using >> >>>> SBDG. *With**out* SBDG, users of Spring Boot would get Geode 1.9 >> due to >> >>>> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would >> >>>> suddenly (possibly) change the Geode version to 1.10. That is >> >>> definitively >> >>>> bad. >> >>>> >> >>>> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9. >> >>>> >> >>>> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not >> >>>> available) which will pull in the latest version of Geode at that >> time >> >>>> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 >> reaches RC >> >>>> status. >> >>>> >> >>>> Cheers, >> >>>> John >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> On Tue, Aug 13, 2019 at 1:45 PM John Blum <jb...@pivotal.io> wrote: >> >>>>> >> >>>>> For clarification... >> >>>>> >> >>>>> 1. SBDG 1.1 is the "*current*" development line (on >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 >> >>>> >> >>>>> master >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 >> > >> >>> [1]); >> >>>>> SBDG 1.2 is *not* yet in development. >> >>>>> 2. SBDG 1.1 is at RC1 >> >>>>> <https://github.com/spring-projects/spring-boot-data-geode/releases >> > >> >>> [2]. >> >>>>> 3. SBDG 1.1 is based on Spring Boot 2.1 >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8 >> > >> >>> [3] >> >>>>> and Spring Data (Geode) Lovelace >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12 >> > >> >>> [4] >> >>>>> (or SDG 2.1 >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10 >> > >> >>> [5]); >> >>>>> This is not arbitrary because all the stars (bits, transitive >> dependency >> >>>>> versions) must "align" as defined by what Spring Boot 2.1 declares, >> and >> >>>>> Spring Boot 2.1 is based on >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169 >> > >> >>> [6] >> >>>>> Spring Data Lovelace/2.1. >> >>>>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25 >> > >> >>> [7] >> >>>>> Apache Geode 1.6. >> >>>>> 5. All SDG Lovelace/2.1.x versions will always be based on the >> latest >> >>>>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of >> time. >> >>>>> This ship has sailed. >> >>>>> >> >>>>> ~~~~ >> >>>>> >> >>>>> 6. SBDG 1.2, when it reaches development (soon),will be based on >> Spring >> >>>>> Boot 2.2 >> >>>>> < >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8 >> > >> >>> [8], >> >>>>> Spring Data (Geode) Moore >> >>>>> < >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12 >> > >> >>> [9] >> >>>>> (or SDG 2.2 >> >>>>> < >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10 >> > >> >>> [10]); >> >>>>> This is also not arbitrary because Spring Boot 2.2 declares a >> dependency >> >>>>> on >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185 >> > >> >>> [11] >> >>>>> Spring Data Moore. Again, the stars must align. >> >>>>> 7. Spring Data Geode (SDG) Moore/2.2 is based on >> >>>>> < >> >>> >> https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25 >> > >> >>> [12] >> >>>>> Apache Geode 1.9.0. >> >>>>> 8. As you can see, SDG Moore/2.2 is already in release candidates >> (i.e. >> >>>>> RC2 or the 2nd release candidate), which means SDG cannot be >> rebased on >> >>>>> 1.10 at this point. The transitive dependency major.minor versions >> are >> >>> now >> >>>>> fixed for SD(G) Moore/2.2. >> >>>>> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. >> >>>>> 1.9.1 up to 1.9.N where N is 0... infinity). >> >>>>> >> >>>>> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or >> 1.11 or >> >>>>> 1.whatever is in the next SD Release Trains, Neuman, or 2.3. SDG >> can >> >>>>> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, >> etc >> >>>>> until SDG Neuman/2.3 reaches it's first release candidate (RC) >> release, >> >>> at >> >>>>> which point the major.minor becomes fixed in that particular SD >> Release >> >>>>> Train, until the next SD Release Train (Neuman.next). >> >>>>> >> >>>>> Make sense? >> >>>>> >> >>>>> So, it is the SDG version (along with Spring Boot core) that SBDG >> >>> depends >> >>>>> on that determines the version of Apache Geode that SBDG pulls in. >> >>>>> >> >>>>> Hope this helps! >> >>>>> >> >>>>> Regards, >> >>>>> John >> >>>>> >> >>>>> >> >>>>> [1] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 >> >>>>> [2] >> https://github.com/spring-projects/spring-boot-data-geode/releases >> >>>>> [3] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8 >> >>>>> [4] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12 >> >>>>> [5] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10 >> >>>>> [6] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169 >> >>>>> [7] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25 >> >>>>> [8] >> >>>>> >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8 >> >>>>> [9] >> >>>>> >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12 >> >>>>> [10] >> >>>>> >> >>> >> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10 >> >>>>> [11] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185 >> >>>>> [12] >> >>>>> >> >>> >> https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25 >> >>>>> >> >>>>> >> >>>>> On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey <alind...@pivotal.io >> > >> >>>>> wrote: >> >>>>> >> >>>>>> Thanks, Udo. >> >>>>>> >> >>>>>> +1 for doing a 1.9.1 patch release, assuming there is enough time >> for >> >>>>>> SBDG to include it in their 1.2.x line. >> >>>>>> >> >>>>>> - Aaron >> >>>>>> >> >>>>>>> On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer <u...@apache.com> >> wrote: >> >>>>>>> >> >>>>>>> No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd >> have >> >>>>>> to wait for SBDG 1.3 to use 1.10 or 1.11 >> >>>>>>> >> >>>>>>> SBDG 1.3 is still a few months off, so maybe getting critical >> fixes >> >>> in >> >>>>>> patch versions is required. >> >>>>>>> >> >>>>>>>> On 8/13/19 11:26 AM, Kirk Lund wrote: >> >>>>>>>> Udo, Thanks for the info! Sounds like we shouldn't bother with >> Geode >> >>>>>> 1.9.1 >> >>>>>>>> then. If I'm misinterpreting what you wrote, let me know. >> >>>>>>>> >> >>>>>>>> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer <u...@apache.com> >> >>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> The latest version of SBDG 1.2 is already in RC stage. Which >> means >> >>>>>> the >> >>>>>>>>> dependent Geode version cannot be changed any more. Currently >> SBDG >> >>>>>> 1.2 >> >>>>>>>>> is based on Geode 1.9. This will not change. Patch versions to >> 1.9 >> >>>>>> are >> >>>>>>>>> supported, but not changes to 1.10 or later. >> >>>>>>>>> >> >>>>>>>>> THUS, >> >>>>>>>>> >> >>>>>>>>> Once SBDG 1.3 (Neuman) is released, it will be based on the >> latest >> >>>>>> GA of >> >>>>>>>>> Geode, which at this point would be 1.10 or possibly 1.11 >> depending >> >>>>>> on >> >>>>>>>>> release cycles. >> >>>>>>>>> >> >>>>>>>>> In addition... >> >>>>>>>>> >> >>>>>>>>> @Aaron, Whilst it would also be possible to override the >> underlying >> >>>>>>>>> Geode version that SBDG uses, to a later version, I would just >> like >> >>>>>> to >> >>>>>>>>> point out that all testing of SBDG will be against a named >> >>> supported >> >>>>>>>>> version of Geode / GemFire. Which means, if failures arise using >> >>>>>> SBDG / >> >>>>>>>>> SDG with a non-supported version of Geode / GemFire would >> >>>>>> effectively be >> >>>>>>>>> unsupported. (due diligence to confirm origin of failure will of >> >>>>>> course >> >>>>>>>>> be applied) >> >>>>>>>>> >> >>>>>>>>> Hope this helps... >> >>>>>>>>> >> >>>>>>>>> --Udo >> >>>>>>>>> >> >>>>>>>>>> On 8/13/19 10:03 AM, Aaron Lindsey wrote: >> >>>>>>>>>> Assuming Geode 1.10 is released with the three logging fixes in >> >>>>>> Kirk’s >> >>>>>>>>> message, can the next GA release of Spring Boot Data Geode >> consume >> >>>>>> 1.10 >> >>>>>>>>> instead of 1.9? Also, when would SBDG need this patch release by >> >>>>>> (whether >> >>>>>>>>> we do a 1.9.1 release or 1.10 release)? >> >>>>>>>>>> - Aaron >> >>>>>>>>>> >> >>>>>>>>>>> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt < >> >>>>>> bschucha...@pivotal.io> >> >>>>>>>>> wrote: >> >>>>>>>>>>> If we release a 1.9.1 I'd like to include the SSL/NIO fix. >> >>> Cluster >> >>>>>> SSL >> >>>>>>>>> communications with conserve-sockets=false is currently broken >> in >> >>>>>> 1.9. >> >>>>>>>>>>>> On 8/13/19 9:25 AM, Kirk Lund wrote: >> >>>>>>>>>>>> I'd like to discuss if and how we can release Geode 1.9.1 >> with >> >>>>>> logging >> >>>>>>>>>>>> improvements. This is primarily to provide a patch release >> for >> >>>>>> Spring >> >>>>>>>>> Data >> >>>>>>>>>>>> Geode and Spring Boot to ensure a smoother User experience >> >>>>>> out-of-the >> >>>>>>>>> box. >> >>>>>>>>>>>> They have very near-future releases that need this as soon as >> >>>>>> possible. >> >>>>>>>>>>>> >> >>>>>>>>>>>> The specific tickets and commits that would be back-ported >> are: >> >>>>>>>>>>>> >> >>>>>>>>>>>> *1. GEODE-7058 Log4j-core dependency should be optional in >> >>>>>> geode-core* >> >>>>>>>>>>>> >> >>>>>>>>>>>> commit 413800bc16d05df689a2af5c30797f180aad6088 >> >>>>>>>>>>>> Author: Kirk Lund <kl...@apache.org> >> >>>>>>>>>>>> Date: Wed Aug 7 14:33:21 2019 -0700 >> >>>>>>>>>>>> >> >>>>>>>>>>>> GEODE-7058: Mark log4j-core optional in geode-core >> >>>>>>>>>>>> >> >>>>>>>>>>>> Note: this change requires all commits from GEODE-2644 and >> >>>>>>>>> GEODE-6122. >> >>>>>>>>>>>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j >> >>> loggers* >> >>>>>>>>>>>> >> >>>>>>>>>>>> commit e5c9c420f462149fd062847904e3435fbe99afb4 >> >>>>>>>>>>>> Author: Kirk Lund <kl...@apache.org> >> >>>>>>>>>>>> Date: Thu Aug 8 18:17:32 2019 -0700 >> >>>>>>>>>>>> >> >>>>>>>>>>>> GEODE-7050: Use Log4jAgent only if Log4j is using >> >>>>>> Log4jProvider >> >>>>>>>>> (#3892) >> >>>>>>>>>>>> This change prevents Geode from using Log4jAgent if Log4j >> >>>>>> Core is >> >>>>>>>>>>>> present but not using Log4jProvider. >> >>>>>>>>>>>> >> >>>>>>>>>>>> For example, Log4j uses SLF4JProvider when log4j-to-slf4j >> >>> is >> >>>>>> in >> >>>>>>>>> the >> >>>>>>>>>>>> classpath. >> >>>>>>>>>>>> >> >>>>>>>>>>>> By disabling Log4jAgent when other Log4j Providers are in >> >>>>>> use, >> >>>>>>>>> this >> >>>>>>>>>>>> prevents problems such as ClassCastExceptions when >> >>> attemping >> >>>>>> to >> >>>>>>>>> cast >> >>>>>>>>>>>> loggers from org.apache.logging.slf4j.SLF4JLogger to >> >>>>>>>>>>>> org.apache.logging.log4j.core.Logger to get the >> >>> LoggerConfig >> >>>>>> or >> >>>>>>>>>>>> LoggerContext. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Co-Authored-By: Aaron Lindsey <alind...@pivotal.io> >> >>>>>>>>>>>> >> >>>>>>>>>>>> *3. GEODE-6959 NPE if AlertAppender is not defined* >> >>>>>>>>>>>> >> >>>>>>>>>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89 >> >>>>>>>>>>>> Author: Kirk Lund <kl...@apache.org> >> >>>>>>>>>>>> Date: Thu Aug 8 14:59:44 2019 -0700 >> >>>>>>>>>>>> >> >>>>>>>>>>>> GEODE-6959: Prevent NPE in GMSMembershipManager for null >> >>>>>>>>> AlertAppender >> >>>>>>>>>>>> (#3899) >> >>>>>>>>>>>> >> >>>>>>>>>>>> If a custom log4j2.xml is used without specifying the >> Geode >> >>>>>>>>>>>> AlertAppender, >> >>>>>>>>>>>> GMSMembershipManager may throw a NullPointerException when >> >>>>>>>>> invoking >> >>>>>>>>>>>> AlertAppender.getInstance().stopSession() during a >> >>>>>>>>> forceDisconnect. This >> >>>>>>>>>>>> change prevents the NullPointerException allowing >> >>>>>> forceDisconnect >> >>>>>>>>> to >> >>>>>>>>>>>> finish. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Users using Spring Boot with Logback are more likely to >> hit >> >>>>>> this >> >>>>>>>>> bug. >> >>>>>>>>>>>> Co-authored-by: Mark Hanson mhan...@pivotal.io >> >>>>>>>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> -- >> >>>>> -John >> >>>>> john.blum10101 (skype) >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> -John >> >>>> john.blum10101 (skype) >> >>>> >> >>> >> >>> >> >>> -- >> >>> -John >> >>> john.blum10101 (skype) >> >>> >> >>
