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) > >>> > >
