I think it makes sense to do a 1.9.1 release for the same reasons that we proposed it originally. It looks like we all missed the VOTE thread (it was on my // todo list). In the past when we’ve had insufficient votes, we've extended the deadline and asked for help reviewing the release.
Anthony > On 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) >>>> >
