I would like to resolve the issue around NOTICE and LICENSE files related to new/removed dependencies on develop, which I have a PR[1] open and would need some guidance. There is some feedback provided by Dick earlier this week and I would like to see if I can get some help.
[1] https://github.com/apache/geode/pull/3313 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 > >
