geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: [DISCUSS] Release Geode 1.9.1 with logging improvements
Date Wed, 28 Aug 2019 20:49:23 GMT
Do folks actually want a 1.9.1 release?

On Wed, Aug 28, 2019 at 1:38 PM Owen Nichols <onichols@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 <abaker@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 <klund@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 <jblum@pivotal.io> wrote:
> >>>
> >>> Sorry, corrections below...
> >>>
> >>>> On Tue, Aug 13, 2019 at 1:54 PM John Blum <jblum@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 <jblum@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 <alindsey@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 <udo@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 <udo@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
<
> >>>>>> bschuchardt@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 <klund@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 <klund@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 <alindsey@pivotal.io>
> >>>>>>>>>>>>
> >>>>>>>>>>>> *3. GEODE-6959 NPE if AlertAppender
is not defined*
> >>>>>>>>>>>>
> >>>>>>>>>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
> >>>>>>>>>>>> Author: Kirk Lund <klund@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 mhanson@pivotal.io
> >>>>>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> -John
> >>>>> john.blum10101 (skype)
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> -John
> >>>> john.blum10101 (skype)
> >>>>
> >>>
> >>>
> >>> --
> >>> -John
> >>> john.blum10101 (skype)
> >>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message