You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@pivotal.io> on 2019/03/19 19:19:29 UTC
[DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
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
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Anilkumar Gingade <ag...@pivotal.io>.
+1 to re-cut.
-Anil.
On Tue, Mar 19, 2019 at 2:11 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 <bs...@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 <onichols@pivotal.io
> > > <ma...@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
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dale Emery <de...@pivotal.io>.
Hi Alexander,
> On Mar 20, 2019, at 9:47 AM, Alexander Murmann <am...@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?
It’s useful, but somewhat less usable than we want it to be. Currently the only way to publish the metrics is to implement a service loader. Dan suggested that we offer additional ways that are easier for Geode users. For example, passing a “publishing registry” to the cache factory. We think that’s a great idea, and we promised to do it, but haven’t done it yet.
Cheers,
Dale
—
Dale Emery
demery@pivotal.io
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <on...@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 <ds...@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 <de...@pivotal.io> wrote:
> >
> >>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
> >> demery@pivotal.io
> >>
> >>
> >>
> >>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <
> amurmann@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 <db...@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 <de...@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
> >>>>>>>> demery@pivotal.io
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> >>>>>>>> bschuchardt@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 <
> >>>>>> onichols@pivotal.io
> >>>>>>>>>>>> <ma...@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
> >>
> >>
>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Owen Nichols <on...@pivotal.io>.
@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 <ds...@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 <de...@pivotal.io> wrote:
>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
>> demery@pivotal.io
>>
>>
>>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <amurmann@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 <db...@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 <de...@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
>>>>>>>> demery@pivotal.io
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
>>>>>>>> bschuchardt@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 <
>>>>>> onichols@pivotal.io
>>>>>>>>>>>> <ma...@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
>>
>>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dan Smith <ds...@pivotal.io>.
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 <de...@pivotal.io> wrote:
> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
> demery@pivotal.io
>
>
>
> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <amurmann@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 <db...@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 <de...@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
> >>>>>> demery@pivotal.io
> >>>>>>
> >>>>>>
> >>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> >>>>>> bschuchardt@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 <
> >>>> onichols@pivotal.io
> >>>>>>>>>> <ma...@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
>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Anthony Baker <ab...@pivotal.io>.
I can help.
> On Mar 20, 2019, at 5:08 PM, Sai Boorlagadda <sa...@gmail.com> wrote:
>
> 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 <de...@pivotal.io> wrote:
>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
>> demery@pivotal.io
>>
>>
>>
>>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <amurmann@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 <db...@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 <de...@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
>>>>>>>> demery@pivotal.io
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
>>>>>>>> bschuchardt@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 <
>>>>>> onichols@pivotal.io
>>>>>>>>>>>> <ma...@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
>>
>>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <de...@pivotal.io> wrote:
> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
> demery@pivotal.io
>
>
>
> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <amurmann@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 <db...@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 <de...@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
> >>>>>> demery@pivotal.io
> >>>>>>
> >>>>>>
> >>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> >>>>>> bschuchardt@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 <
> >>>> onichols@pivotal.io
> >>>>>>>>>> <ma...@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
>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dale Emery <de...@pivotal.io>.
> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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
demery@pivotal.io
> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <aj...@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 <db...@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 <db...@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 <am...@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 <db...@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 <de...@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
>>>>>> demery@pivotal.io
>>>>>>
>>>>>>
>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
>>>>>> bschuchardt@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 <
>>>> onichols@pivotal.io
>>>>>>>>>> <ma...@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
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Alexander Murmann <aj...@gmail.com>.
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 <db...@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 <db...@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 <am...@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 <db...@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 <de...@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
> >> > > demery@pivotal.io
> >> > >
> >> > >
> >> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> >> > > bschuchardt@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 <
> >> onichols@pivotal.io
> >> > > >>>> <ma...@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
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dave Barnes <db...@apache.org>.
geode-native is ready to into the 1.9 release candidate build.
On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes <db...@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 <am...@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 <db...@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 <de...@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
>> > > demery@pivotal.io
>> > >
>> > >
>> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
>> > > bschuchardt@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 <
>> onichols@pivotal.io
>> > > >>>> <ma...@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
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dave Barnes <db...@pivotal.io>.
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 <am...@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 <db...@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 <de...@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
> > > demery@pivotal.io
> > >
> > >
> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> > > bschuchardt@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 <
> onichols@pivotal.io
> > > >>>> <ma...@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
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Alexander Murmann <am...@apache.org>.
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 <db...@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 <de...@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
> > demery@pivotal.io
> >
> >
> > > On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> > bschuchardt@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 <onichols@pivotal.io
> > >>>> <ma...@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
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dave Barnes <db...@apache.org>.
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 <de...@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
> demery@pivotal.io
>
>
> > On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <
> bschuchardt@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 <onichols@pivotal.io
> >>>> <ma...@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
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dale Emery <de...@pivotal.io>.
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
demery@pivotal.io
> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <bs...@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 <onichols@pivotal.io
>>>> <ma...@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
>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Owen Nichols <on...@pivotal.io>.
Manageability just yesterday moved all work-in-progress behind a feature flag; yes, we are comfortable releasing in the current state.
> On Mar 19, 2019, at 3:29 PM, Dan Smith <ds...@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 <bs...@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 <onichols@pivotal.io
>>>> <ma...@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
>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dan Smith <ds...@pivotal.io>.
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 <bs...@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 <onichols@pivotal.io
> > > <ma...@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
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Alexander Murmann <am...@apache.org>.
+1. We want to ship with confidence and we have more trust in develop right
now.
On Tue, Mar 19, 2019 at 2:11 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 <bs...@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 <onichols@pivotal.io
> > > <ma...@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
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Dick Cavender <di...@apache.org>.
+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 <bs...@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 <onichols@pivotal.io
> > <ma...@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
> >
> >
> >
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <onichols@pivotal.io
> <ma...@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
>
>
>
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Posted by Sai Boorlagadda <sa...@gmail.com>.
> 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 <on...@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
>
>
>
>