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
