I'm fine releasing with just the service loader API for micrometer. I'd just like the folks working on these new public APIs agree that they are ok with these APIs getting released to end users and put to use in the state they are right now.
-Dan 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 > >
