geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Wed, 07 Aug 2019 22:23:44 GMT
There appears to be consensus that this is a critical fix.

The following commits have been brought into support/1.10.0 <https://github.com/apache/geode/tree/release/1.10.0>
as the critical fix for GEODE-7051 <https://issues.apache.org/jira/browse/GEODE-7051>:

git cherry-pick -x 413800bc16d05df689a2af5c30797f180aad6088 <https://github.com/apache/geode/commit/413800bc16d05df689a2af5c30797f180aad6088>
git cherry-pick -x e1b61cdcaf38966bbb732b0b3db5223f2cc4f5e4 <https://github.com/apache/geode/commit/e1b61cdcaf38966bbb732b0b3db5223f2cc4f5e4>

GEODE-7051 <https://issues.apache.org/jira/browse/GEODE-7051> has been marked as 'resolved
in' 1.10.0.

-Owen

> On Aug 6, 2019, at 1:39 PM, Bruce Schuchardt <bschuchardt@pivotal.io> wrote:
> 
> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message