geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Emery <dem...@pivotal.io>
Subject Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Date Wed, 20 Mar 2019 19:37:15 GMT
> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <ajmurmann@gmail.com> wrote:
> 
> Dale, is there any downside to making these changes in 1.10 other than
> plainly having them later?

I don’t think so, but I’d want to hear Dan’s opinion on that, given that his approval
of our PR was contingent on our promise to do it.

FYI, the additional work to improve usability is non-trivial, which is why we haven’t done
it already.

—
Dale Emery
demery@pivotal.io



> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <ajmurmann@gmail.com> wrote:
> 
> Dale, is there any downside to making these changes in 1.10 other than
> plainly having them later?
> 
> On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes <dbarnes@apache.org> wrote:
> 
>> geode-native is ready to into the 1.9 release candidate build.
>> 
>> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes <dbarnes@pivotal.io> wrote:
>> 
>>> The geode-native PR will be ready to check in momentarily. Just waiting
>>> for Travis to do its diligence.
>>> 
>>> On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann <amurmann@apache.org>
>>> wrote:
>>> 
>>>> Dale, do I understand correctly that the only concern around the
>>>> Micrometer
>>>> work right now it that it's not useful yet, however it's not harmful
>>>> either?
>>>> 
>>>> Dave, is it correct that if that PR doesn't make it into the newly cut
>>>> branch, we'd be shipping with a older version of geode-native? What are
>>>> the
>>>> two versions and what would be the implications of this not making it
>> into
>>>> this release?
>>>> 
>>>> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes <dbarnes@apache.org> wrote:
>>>> 
>>>>> The Geode 1.9.0 release includes a source-only release of the
>>>> geode-native
>>>>> repo. There's a pull-request in process to update version numbers and
>>>> the
>>>>> doc build environment in that repo; should be ready to merge tomorrow
>>>>> morning.
>>>>> 
>>>>> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery <demery@pivotal.io>
wrote:
>>>>> 
>>>>>> The Micrometer API is in, and marked as experimental. But we have
>> not
>>>> yet
>>>>>> updated CacheFactory to allow injecting a meter registry (or metrics
>>>>>> publishing service) there. So currently the only way to publish is
>> to
>>>> add
>>>>>> metrics publishing service via the ServiceLoader mechanism.
>>>>>> 
>>>>>> —
>>>>>> Dale Emery
>>>>>> demery@pivotal.io
>>>>>> 
>>>>>> 
>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <dsmith@pivotal.io>
wrote:
>>>>>>> 
>>>>>>> Is the geode-managability sub-project and the new micrometer
API
>> in
>>>> a
>>>>>> place
>>>>>>> where we can cut a release branch? I know a bunch of changes
have
>>>> gone
>>>>> in
>>>>>>> since the release branch, are we comfortable releasing these
new
>>>>>>> experimental features as they are right now?
>>>>>>> 
>>>>>>> -Dan
>>>>>>> 
>>>>>>> On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender <dixie@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> +1 to re-cutting the 1.9 release branch off a more stable
develop
>>>> sha
>>>>>>>> within the last couple days.
>>>>>>>> 
>>>>>>>> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
>>>>>> bschuchardt@pivotal.io>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> If we recut the release branch we need to update JIRA
tickets
>>>> marked
>>>>>>>>> fixed in 1.10
>>>>>>>>> 
>>>>>>>>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
>>>>>>>>>>> It was known at the time that develop was not
as stable as
>>>> desired,
>>>>>>>>>> so we planned to cherry-pick fixes from develop until
the
>> release
>>>>>>>>>> branch was stable enough to ship.
>>>>>>>>>> I want to clarify that we decided to cut the release
branch not
>>>> that
>>>>>>>>>> develop was not stable. But really that it is desirable
to cut
>>>> the
>>>>>>>>>> branch sooner to avoid any regression risk that can
be
>>>> introduced by
>>>>>>>>>> on-going work on develop.
>>>>>>>>>> 
>>>>>>>>>> Nevertheless looks like develop is more stable than
release
>>>> branch
>>>>> due
>>>>>>>>>> to some test fixes that were not cherry-picked into
the release
>>>>>> branch.
>>>>>>>>>> I think its a good idea to re-cut the branch as our
current
>>>> position
>>>>>>>>>> to stabilize release branch before releasing.
>>>>>>>>>> 
>>>>>>>>>> +1 to re-cut.
>>>>>>>>>> 
>>>>>>>>>> Sai
>>>>>>>>>> 
>>>>>>>>>> On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
>>>> onichols@pivotal.io
>>>>>>>>>> <mailto:onichols@pivotal.io>> wrote:
>>>>>>>>>> 
>>>>>>>>>>   The Geode 1.9.0 release branch was originally cut
4 weeks
>> ago
>>>> on
>>>>>>>>>>   Feb 19.  It was known at the time that develop
was not as
>>>> stable
>>>>>>>>>>   as desired, so we planned to cherry-pick fixes
from develop
>>>> until
>>>>>>>>>>   the release branch was stable enough to ship. 
While this
>> is a
>>>>>>>>>>   good strategy when starting from a fairly good
baseline, it
>>>> seems
>>>>>>>>>>   in this case it has only added complexity without
leading to
>>>>>>>>>>   stability.
>>>>>>>>>> 
>>>>>>>>>>   Looking at the pipelines over the last week (see
attached
>>>>>>>>>>   metrics), it appears we have been far more successful
at
>>>>>>>>>>   stabilizing /develop/ than /release/1.9.0/. Rather
than
>>>> trying to
>>>>>>>>>>   cherry-pick more and more fixes to the release
branch, I
>>>> propose
>>>>>>>>>>   we RE-CUT the 1.9.0 release branch later this week
in order
>> to
>>>>>>>>>>   start from a much more stable baseline.
>>>>>>>>>> 
>>>>>>>>>>   -Owen
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Alexander J. Murmann
> (650) 283-1933


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