geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Boorlagadda <sai.boorlaga...@gmail.com>
Subject Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Date Mon, 25 Mar 2019 13:38:41 GMT
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 <onichols@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 <dsmith@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 <demery@pivotal.io> wrote:
> >
> >>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann <ajmurmann@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 <ajmurmann@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 <dbarnes@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 <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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Alexander J. Murmann
> >>> (650) 283-1933
> >>
> >>
>
>

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