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