geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nabarun Nag <n...@pivotal.io>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Tue, 06 Aug 2019 20:33:14 GMT
+1 on getting the Fix [Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.] in.


Spring Data for Apache Geode has been removed from Spring Initializr
because of the issue with  log4j dependencies, also IntelliJ doesn't list
it as a NoSQL dependency. I would prefer that it is resolved in this
release and not wait for 3-4 months.

Regards
Naba



On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols <onichols@pivotal.io> wrote:

> Hi Kirk, thank you for bringing your concern.
>
> Yes, release/1.10.0 was created last week <
> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
> as planned.  Our current process <
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
> dictates a time-based schedule to cut release branches.  Once cut, the
> “critical fixes” rule allows critical fixes to be brought to the release
> branch by proposal on the dev list.
>
> Currently the 1.10.0 release pipeline <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
> is all green.  If there is consensus from the Geode community that this
> log4j change satisfies the “critical fixes” rule, Dick or I will be happy
> to bring it to the 1.10.0 release branch.
>
> -Owen
>
> > On Aug 6, 2019, at 12:49 PM, Kirk Lund <klund@apache.org> wrote:
> >
> > Did we already cut the 1.10 branch?
> >
> > I'd like to find out if it's possible to get a change into 1.10: Upgrade
> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> > in the geode-core pom.
> >
> > Getting this change into 1.10 will make things much easier for Spring
> Boot
> > Data Geode. When using Geode with Spring Boot, log4j-core has to be
> > manually excluded so that logback can be used instead. The change to
> log4j
> > 2.12.0 will also help as they have already have some dependency on 2.12.0
> > (probably log4j-to-slf4j). I can find out more precise details if needed.
> >
> > On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender <dixie@apache.org> wrote:
> >
> >> In preparation for cutting the release branch have we confirmed that
> >> Geode's LICENSE and NOTICE file been confirmed to accurately reflect
> what
> >> is being shipped for v1.10?
> >>
> >> From Apache: http://www.apache.org/dev/licensing-howto.html
> >> *"*The LICENSE and NOTICE files must exactly represent the contents of
> the
> >> distribution they reside in."
> >>
> >> Ideally this is kept up to date during development as the dependencies
> >> change or are added but this often is missed and needs to be reconciled
> on
> >> develop before we cut a release branch.
> >>
> >> -Dick
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols <onichols@pivotal.io>
> wrote:
> >>
> >>> From that email:
> >>>
> >>> To make this work, it's important to be strict
> >>> about cutting the release branch on the set date and only allow
> critical
> >>> fixes after the release has been cut. Once we start compromising on
> this,
> >>> we go down a slippery slope that ultimately leads to not getting the
> >>> predictability benefits described here.
> >>>
> >>> We are perilously close to the "slippery slope”:
> >>> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
> >>> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
> >>> already on cutting the 1.10 branch
> >>>
> >>> It seems like the community reaction to branching from the SHA
> initially
> >>> proposed is “woah, not quite yet”.
> >>>
> >>> To get last-minute stuff in (or out) and get back on track, I propose
> >>> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday
> August
> >> 1.
> >>>
> >>> -Owen
> >>>
> >>>
> >>>> On Jul 30, 2019, at 5:31 PM, Alexander Murmann <amurmann@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi Karen,
> >>>>
> >>>> Here is the previous discussion that was very positively received:
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >>>>
> >>>> However, JIRA tells me that GEODE-7013 is already fixed. If we were
to
> >> go
> >>>> with a SHA from this week, for which Jake also chimed in with plenty
> of
> >>>> reasons, this should be in the release.
> >>>>
> >>>> On Tue, Jul 30, 2019 at 5:10 PM Karen Miller <kmiller@pivotal.io>
> >> wrote:
> >>>>
> >>>>> Alexander, can you point me at the policy decision for the "critical
> >>> issue"
> >>>>> rule you mention? I always though it was up
> >>>>> to the release manager.
> >>>>>
> >>>>> I want GEODE-7013 fixes in because it is the right thing to do.
 Our
> >>> gfsh
> >>>>> help/hint wasn't working the way we say that it did.
> >>>>> With the fix, it does.  I want either the documentation to match
the
> >>> code,
> >>>>> or I want the code to match the documentation.
> >>>>> The fix in GEODE-7013 changes the code to match the existing
> >>> documentation,
> >>>>> so we don't have to change the documentation
> >>>>> (which would have needed to be cherry-picked into our 1.10 release
> >>> branch).
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols <onichols@pivotal.io>
> >>> wrote:
> >>>>>
> >>>>>> Our "critical issue” rule has the effect that the bar to commit
to
> >>>>> develop
> >>>>>> is “low”, but the bar to cherry-pick to support branch is
“very
> >> high”.
> >>>>>>
> >>>>>> Contributors could plan around this disparity more easily if
any of
> >> the
> >>>>>> following were true:
> >>>>>> - releases were more frequent
> >>>>>> - planned cut date of release branch was announced in advance
> (rather
> >>>>> than
> >>>>>> retroactively)
> >>>>>> - a process existed for making exceptions to the “critical
issue”
> >> rule
> >>>>>>
> >>>>>> I agree that the proposed SHA looks like a relatively stable
> >>> branchpoint
> >>>>>> (coming near the end of a nice period of solid green in the
> >> pipeline),
> >>>>> and
> >>>>>> I acknowledge that fair warning was given a week ago that a
branch
> >> was
> >>>>>> “coming soon”, but I wonder if there is anything we can
do to make
> >> the
> >>>>>> rules for what gets in a release and what doesn’t feel a little
less
> >>>>>> arbitrary?
> >>>>>>
> >>>>>> -Owen
> >>>>>>
> >>>>>>
> >>>>>>> On Jul 30, 2019, at 11:16 AM, Alexander Murmann <
> >> amurmann@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Dick, thank you for stepping up!
> >>>>>>>
> >>>>>>> I think it's great to cut the branch sooner rather than
later.
> There
> >>>>>>> already is GEODE-7012 which introduces a distributed deadlock
> during
> >>>>>>> startup. That seems like a critical issue to fix. That should
be
> >> able
> >>>>> to
> >>>>>>> happen after we cut the branch though.
> >>>>>>>
> >>>>>>> Karen, I wonder if that could be merged after the branch
got cut,
> >> but
> >>>>>> also
> >>>>>>> wonder if that fits our "critical issue" rule for being
merged
> after
> >>>>> the
> >>>>>>> branch has been cut or hold up the release. This has been
broken
> >> since
> >>>>> a
> >>>>>>> very long time. Thoughts?
> >>>>>>>
> >>>>>>> On Tue, Jul 30, 2019 at 10:51 AM Karen Miller <kmiller@pivotal.io>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I'd like to see the changes from
> >>>>>>>> https://issues.apache.org/jira/browse/GEODE-7013 included
in the
> >>>>> Geode
> >>>>>>>> 1.10
> >>>>>>>> release. GEODE-7013's changes restore gfsh help/hint
behavior that
> >>> was
> >>>>>> lost
> >>>>>>>> during a refactor in the earliest
> >>>>>>>> releases of Geode.  The commit occurred after SHA1
> >>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> >>>>>>>> Thanks.  Karen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender <dixie@apache.org>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I'll take on the Release Manager role for Geode
1.10 with the
> >> 1.9.0
> >>>>>>>> release
> >>>>>>>>> manager's help (Owen:).
> >>>>>>>>>
> >>>>>>>>> I'd like to propose cutting the release/1.10 branch
off develop
> >> sha:
> >>>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> >>>>>>>>>
> >>>>>>>>> aka: 1.10.0-SNAPSHOT.476
> >>>>>>>>>
> >>>>>>>>> Please speak up and discuss. We'll then start taking
> >> considerations
> >>>>> for
> >>>>>>>>> additional changes for 1.1.0 after we get the branch
and pipeline
> >> in
> >>>>>>>> place.
> >>>>>>>>>
> >>>>>>>>> -Dick
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann
<
> >>>>> amurmann@apache.org
> >>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for calling this out Ernie!
> >>>>>>>>>>
> >>>>>>>>>> It might be a good idea to cut the release and
at the same time
> >>> keep
> >>>>>>>>>> looking for urgent issues that need to be resolved
and merged.
> >> Once
> >>>>>> the
> >>>>>>>>>> branch is cut, we release likelihood of new
issues being
> >>> introduced.
> >>>>>>>>>>
> >>>>>>>>>> Does anyone know of any other issues, we'd want
to make sure get
> >>>>>>>>> addressed
> >>>>>>>>>> before we ship?
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt
<
> >>>>>>>> eburghardt@pivotal.io>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> There is a PR #3844 <https://github.com/apache/geode/pull/3844
> >
> >>> up
> >>>>>>>> to
> >>>>>>>>>>> address GEODE-7012 <
> >>>>> https://issues.apache.org/jira/browse/GEODE-7012
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>>> think this should be in the next release...
> >>>>>>>>>>>
> >>>>>>>>>>> EB
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Jul 26, 2019 at 4:07 PM Alexander
Murmann <
> >>>>>>>> amurmann@apache.org
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> *Cutting the release*
> >>>>>>>>>>>> Do we have any volunteers to take over
the release manager
> >> role?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *Re: Udo's concerns*
> >>>>>>>>>>>> While I believe that iterations of this
particular work have
> >> been
> >>>>>>>>>>> discussed
> >>>>>>>>>>>> on the mailing list as far back as March
2018, I do think that
> >> we
> >>>>>>>>>> should
> >>>>>>>>>>>> take Udo's response as an indicator
that something with our
> >>> larger
> >>>>>>>>>>> proposal
> >>>>>>>>>>>> process needs to be improved. We used
to have synchronous
> Geode
> >>>>>>>> club
> >>>>>>>>>>> house
> >>>>>>>>>>>> sessions. For future discussions and
for proposals in
> >> particular,
> >>>>> I
> >>>>>>>>>> think
> >>>>>>>>>>>> it would be great to supplement our
asynchronous mailing list
> >>>>>>>>>>> communication
> >>>>>>>>>>>> with a synchronous video chat discussions
by the community.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Jul 26, 2019 at 4:02 PM Dan
Smith <dsmith@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +1 for cutting a 1.10.0 release
branch.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Jul 26, 2019 at 3:55 PM
Nabarun Nag <nnag@apache.org
> >
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>> I believe the original authors
of the feature has done their
> >>>>>>>> due
> >>>>>>>>>>>>> diligence
> >>>>>>>>>>>>>> and followed all steps, we can
get this feature in under the
> >>>>>>>>>>>> Experimental
> >>>>>>>>>>>>>> flag and let the community improve
on it, if there is
> >> anything
> >>>>>>>>> else
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>> needs to be done.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We have done this before for
Lucene re-index feature, where
> >> we
> >>>>>>>>>>> involved
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>> entire community in its development,
phase by phase. The
> wiki
> >>>>>>>> is
> >>>>>>>>> up
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> running, if someone has any
concerns can raise it as a JIRA
> >> or
> >>>>>>>>>>> comment
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>> the wiki and the community as
a whole can decide if it is a
> >>>>>>>> valid
> >>>>>>>>>>>>>> concern or not and act upon
it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>> Nabarun Nag
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 3:40
PM Udo Kohlmeyer <
> >> udo@apache.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> @Alexander + @Jared,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So maybe that was my misunderstanding
on the RFC (not being
> >>>>>>>>>>> optional
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>> new feature work). Given
that this is a new feature, there
> >> is
> >>>>>>>>>>>>>>> significant risk to getting
it "wrong".
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I was expecting more discussion
around this. I have some
> >>>>>>>>>> objections
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>> the current approach/design.
Given that my day job does not
> >>>>>>>>> allow
> >>>>>>>>>>> me
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>> respond in a timely manner,
I would have not been able to
> >> get
> >>>>>>>>> all
> >>>>>>>>>>> my
> >>>>>>>>>>>>>>> concerns raised. In addition,
throwing something onto the
> >>>>>>>> wiki,
> >>>>>>>>>> and
> >>>>>>>>>>>>> then
> >>>>>>>>>>>>>>> a few weeks before we'd
like to cut a version raising a
> >>>>>>>>>> discussion
> >>>>>>>>>>>>>>> thread on work that has
been going on for months already
> >> does
> >>>>>>>>> not
> >>>>>>>>>>>> help
> >>>>>>>>>>>>>>> with the community being
able to read, digest, think,
> reason
> >>>>>>>>> and
> >>>>>>>>>>>>> respond
> >>>>>>>>>>>>>>> BEFORE it is released.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I know `@Experimental` is
non-binding on API's or usage,
> BUT
> >>>>>>>> I
> >>>>>>>>>>> prefer
> >>>>>>>>>>>>>>> some of the ground work
to have been discussed, API's
> >>>>>>>> validated
> >>>>>>>>>>>> BEFORE
> >>>>>>>>>>>>>>> it is released into the
wild. I mean this is a PUBLIC API,
> >> so
> >>>>>>>>>> we'd
> >>>>>>>>>>>>>>> prefer to get it more correct
than the previous one.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Maybe it is just me, taking
it too serious... Where I
> prefer
> >>>>>>>>> not
> >>>>>>>>>>>>> release
> >>>>>>>>>>>>>>> something as close to 95%
correct (and discussed).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Anyway.. If we want to cut
1.10... and we should... Let's
> do
> >>>>>>>>> so..
> >>>>>>>>>>> but
> >>>>>>>>>>>>>>> I'd prefer that more on
the correctness on the approach.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/25/19 11:08 AM, Alexander
Murmann wrote:
> >>>>>>>>>>>>>>>>> I don't believe
we should be including anything into the
> >>>>>>>>> Geode
> >>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>> that has not gone
through the correct process of feature
> >>>>>>>>>>> proposal.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> All work under the
experimental cluster management
> service
> >>>>>>>>> has
> >>>>>>>>>>> not
> >>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>> been approved by
the agreed upon RFC process.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Udo, I didn't take the
RFC process that we agreed on to be
> >>>>>>>> a
> >>>>>>>>>> gate
> >>>>>>>>>>>>>> keeper,
> >>>>>>>>>>>>>>>> but rather a way to
de-risk work before making a PR.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> From the RFC doc in
the wiki:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> When to write an
RFC?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Writing an RFC should
be entirely voluntary. There is
> >>>>>>>> always
> >>>>>>>>>> the
> >>>>>>>>>>>>>> option
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> going straight to
a pull request. However, for larger
> >>>>>>>>> changes,
> >>>>>>>>>>> it
> >>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> wise to de-risk
the risk of rejection of the pull request
> >>>>>>>> by
> >>>>>>>>>>> first
> >>>>>>>>>>>>>>>>> gathering input
from the community. Therefore it’s up to
> >>>>>>>>> every
> >>>>>>>>>>>>> member
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> our community to
decide themselves when they want to
> reach
> >>>>>>>>> for
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>> tool.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If we want to change
the role of the RFC process, that's
> >>>>>>>> fine
> >>>>>>>>>>> with
> >>>>>>>>>>>>> me,
> >>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>> we should have that
discussion first.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Jul 23, 2019
at 10:30 AM Jared Stewart <
> >>>>>>>>>>>>>> stewart.jared@gmail.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What was missing
from the RFC process for the cluster
> >>>>>>>>>> management
> >>>>>>>>>>>>>>> service?
> >>>>>>>>>>>>>>>>> I saw a [Discuss]
thread for it, as well as a proposal at
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Jul 23,
2019 at 10:02 AM Udo Kohlmeyer <
> >>>>>>>>>> udo@apache.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I don't believe
we should be including anything into the
> >>>>>>>>>> Geode
> >>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>> that has not
gone through the correct process of feature
> >>>>>>>>>>>> proposal.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All work under
the experimental cluster management
> >>>>>>>> service
> >>>>>>>>>> has
> >>>>>>>>>>>> not
> >>>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>>> been approved
by the agreed upon RFC process.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I don't believe
we should be including this work,
> >>>>>>>>>> experimental
> >>>>>>>>>>> or
> >>>>>>>>>>>>>>>>>> otherwise.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/22/19 4:51
PM, Alexander Murmann wrote:
> >>>>>>>>>>>>>>>>>>> Udo, do
you mind explaining how the RFC process comes
> >>>>>>>> into
> >>>>>>>>>>> this?
> >>>>>>>>>>>>> Are
> >>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>> suggesting
that we should wait if an RFC had a target
> >>>>>>>>>> release
> >>>>>>>>>>>>>>> attached?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mon,
Jul 22, 2019 at 4:47 PM Udo Kohlmeyer <
> >>>>>>>>>> udo@apache.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I don't
think we need to wait for this, as there has
> >>>>>>>> been
> >>>>>>>>>> no
> >>>>>>>>>>>> RFC
> >>>>>>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>>>>> followed.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 7/22/19
3:38 PM, Jinmei Liao wrote:
> >>>>>>>>>>>>>>>>>>>>>
Work is still being planned to move the cluster
> >>>>>>>>> management
> >>>>>>>>>>>> rest
> >>>>>>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>>>>>>>
under an experimental version flag and use a geode
> >>>>>>>>>> property
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> turn
> >>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>
on/off. I would say we are ready to cut the geode
> >>>>>>>> 1.10.0
> >>>>>>>>>>> after
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>
complete.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <
> >>>>>>>>>>>>>>>>> amurmann@apache.org
> >>>>>>>>>>>>>>>>>>>>>
wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
Hi everyone!
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
We released Geode 1.9.0 on April 25th. That's about
> 3
> >>>>>>>>>>> months
> >>>>>>>>>>>>> ago.
> >>>>>>>>>>>>>>>>> End
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>
last year we discussed releasing quarterly. In the
> >>>>>>>> past
> >>>>>>>>>>> we've
> >>>>>>>>>>>>> had
> >>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>
month between cutting a release branch and actually
> >>>>>>>>>>> shipping
> >>>>>>>>>>>>> our
> >>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>> minor.
> >>>>>>>>>>>>>>>>>>>>>>
This means we are already behind our target release
> >>>>>>>>>>> cadence.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
What are your thoughts on cutting a 1.10.0 release
> >>>>>>>>> branch
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>> week?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
Would anyone like to volunteer to be the release
> >>>>>>>>> manager
> >>>>>>>>>>> for
> >>>>>>>>>>>>>> geode
> >>>>>>>>>>>>>>>>>>>> 1.10.0?
> >>>>>>>>>>>>>>>>>>>>>>
Thank you all!
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

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