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 > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > > >
