Thanks Owen. I am going to re-cut the branch for 1.9.0 and request community to do the sanity check for the new branch.
On Fri, Mar 22, 2019 at 4:24 PM Owen Nichols <onich...@pivotal.io> wrote: > @Sai, this discussion has received no objections and enough +1’s to > proceed with re-cutting the release 1.9.0 branch. > > Looking at the pipeline this week, it has been pretty green since SHA > ec5a24b78c51b6a29b8bf656f91004d09510d244. I recommend re-cutting the 1.9.0 > release branch from this SHA. > > -Owen > > > On Mar 21, 2019, at 9:26 AM, Dan Smith <dsm...@pivotal.io> wrote: > > > > 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 > >> > >> > >
