geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <dsm...@pivotal.io>
Subject Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Date Thu, 21 Mar 2019 16:26:49 GMT
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