geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nabarun Nag <n...@apache.org>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Tue, 06 Aug 2019 21:20:45 GMT
Hi,

The commit mentioned in the earlier email has now been reverted on develop
and release/1.10.0 branches.
Thank you for your patience.

Regards
Nabarun Nag


On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag <nnag@apache.org> wrote:

> Hi Geode Community,
>
> After some further analysis, few of the threads are hanging in our
> application using the release branch. Here is an example stacktrace.
> *** Hung thread
>
> "vm_5_thr_5_client1_host1_21862" #457 daemon prio=5 os_prio=0 tid=0x00007fc204009800
nid=0x69aa waiting on condition [0x00007fc1de195000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>
>   - parking to wait for  <0x00000000f10d8098> (a java.util.concurrent.CountDownLatch$Sync)
>   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
>
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
>
>   at org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
>
>   at org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
>
>   at org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
>
>   at org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
>
>   at org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
>
>   at org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.waitForCacheOrFunctionException(FunctionStreamingResultCollector.java:439)
>
>   at org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:90)
>
> We did some further investigation and we presume that it was introduced by
> the following commit.
> GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r…
> (#3853)
>
> We are planning to revert this commit in the release branch as this is a
> necessary fix that needs to be in the release.
>
> Regards
> Nabarun Nag
>
>
>
> On Tue, 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