geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Schuchardt <bschucha...@pivotal.io>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Tue, 06 Aug 2019 20:39:22 GMT
+1

On 8/6/19 1:33 PM, Nabarun Nag wrote:
> +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
View raw message