I can help.
> On Mar 20, 2019, at 5:08 PM, Sai Boorlagadda <sai.boorlaga...@gmail.com>
> wrote:
>
> I would like to resolve the issue around NOTICE and LICENSE files related
> to new/removed dependencies on develop, which I have a PR[1] open and would
> need some guidance.
> There is some feedback provided by Dick earlier this week and I would like
> to see if I can get some help.
>
> [1] https://github.com/apache/geode/pull/3313
>
> On Wed, Mar 20, 2019 at 12:43 PM Dale Emery <dem...@pivotal.io> wrote:
>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <ajmurm...@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
>> dem...@pivotal.io
>>
>>
>>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <ajmurm...@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 <dbar...@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 <dbar...@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 <amurm...@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 <dbar...@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 <dem...@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
>>>>>>>> dem...@pivotal.io
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <dsm...@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 <di...@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 <
>>>>>>>> bschucha...@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 <
>>>>>> onich...@pivotal.io
>>>>>>>>>>>> <mailto:onich...@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
>>
>>
