geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Barnes <dbar...@apache.org>
Subject Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Date Wed, 20 Mar 2019 18:15:02 GMT
geode-native is ready to into the 1.9 release candidate build.

On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes <dbarnes@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 <dbarnes@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 <demery@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 <dsmith@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 <dixie@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
>> > > >>>> <mailto:onichols@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
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message