geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Murmann <amurm...@apache.org>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Tue, 30 Jul 2019 18:16:32 GMT
Dick, thank you for stepping up!

I think it's great to cut the branch sooner rather than later. There
already is GEODE-7012 which introduces a distributed deadlock during
startup. That seems like a critical issue to fix. That should be able to
happen after we cut the branch though.

Karen, I wonder if that could be merged after the branch got cut, but also
wonder if that fits our "critical issue" rule for being merged after the
branch has been cut or hold up the release. This has been broken since a
very long time. Thoughts?

On Tue, Jul 30, 2019 at 10:51 AM Karen Miller <kmiller@pivotal.io> wrote:

> I'd like to see the changes from
> https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode
> 1.10
> release. GEODE-7013's changes restore gfsh help/hint behavior that was lost
> during a refactor in the earliest
> releases of Geode.  The commit occurred after SHA1
> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> Thanks.  Karen
>
>
> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender <dixie@apache.org> wrote:
>
> > I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
> release
> > manager's help (Owen:).
> >
> > I'd like to propose cutting the release/1.10 branch off develop sha:
> > dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> >
> > aka: 1.10.0-SNAPSHOT.476
> >
> > Please speak up and discuss. We'll then start taking considerations for
> > additional changes for 1.1.0 after we get the branch and pipeline in
> place.
> >
> > -Dick
> >
> >
> >
> >
> > On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <amurmann@apache.org>
> > wrote:
> >
> > > Thanks for calling this out Ernie!
> > >
> > > It might be a good idea to cut the release and at the same time keep
> > > looking for urgent issues that need to be resolved and merged. Once the
> > > branch is cut, we release likelihood of new issues being introduced.
> > >
> > > Does anyone know of any other issues, we'd want to make sure get
> > addressed
> > > before we ship?
> > >
> > > On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
> eburghardt@pivotal.io>
> > > wrote:
> > >
> > > > There is a PR #3844 <https://github.com/apache/geode/pull/3844>
up
> to
> > > > address GEODE-7012 <https://issues.apache.org/jira/browse/GEODE-7012
> >
> > I
> > > > think this should be in the next release...
> > > >
> > > > EB
> > > >
> > > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
> amurmann@apache.org
> > >
> > > > wrote:
> > > >
> > > > > *Cutting the release*
> > > > > Do we have any volunteers to take over the release manager role?
> > > > >
> > > > > *Re: Udo's concerns*
> > > > > While I believe that iterations of this particular work have been
> > > > discussed
> > > > > on the mailing list as far back as March 2018, I do think that we
> > > should
> > > > > take Udo's response as an indicator that something with our larger
> > > > proposal
> > > > > process needs to be improved. We used to have synchronous Geode
> club
> > > > house
> > > > > sessions. For future discussions and for proposals in particular,
I
> > > think
> > > > > it would be great to supplement our asynchronous mailing list
> > > > communication
> > > > > with a synchronous video chat discussions by the community.
> > > > >
> > > > > On Fri, Jul 26, 2019 at 4:02 PM Dan Smith <dsmith@pivotal.io>
> wrote:
> > > > >
> > > > > > +1 for cutting a 1.10.0 release branch.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag <nnag@apache.org>
> > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > I believe the original authors of the feature has done
their
> due
> > > > > > diligence
> > > > > > > and followed all steps, we can get this feature in under
the
> > > > > Experimental
> > > > > > > flag and let the community improve on it, if there is anything
> > else
> > > > > that
> > > > > > > needs to be done.
> > > > > > >
> > > > > > > We have done this before for Lucene re-index feature, where
we
> > > > involved
> > > > > > the
> > > > > > > entire community in its development, phase by phase. The
wiki
> is
> > up
> > > > and
> > > > > > > running, if someone has any concerns can raise it as a
JIRA or
> > > > comment
> > > > > in
> > > > > > > the wiki and the community as a whole can decide if it
is a
> valid
> > > > > > > concern or not and act upon it.
> > > > > > >
> > > > > > > Regards
> > > > > > > Nabarun Nag
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer <udo@apache.com>
> > > > wrote:
> > > > > > >
> > > > > > > > @Alexander + @Jared,
> > > > > > > >
> > > > > > > > So maybe that was my misunderstanding on the RFC (not
being
> > > > optional
> > > > > on
> > > > > > > > new feature work). Given that this is a new feature,
there is
> > > > > > > > significant risk to getting it "wrong".
> > > > > > > >
> > > > > > > > I was expecting more discussion around this. I have
some
> > > objections
> > > > > to
> > > > > > > > the current approach/design. Given that my day job
does not
> > allow
> > > > me
> > > > > to
> > > > > > > > respond in a timely manner, I would have not been
able to get
> > all
> > > > my
> > > > > > > > concerns raised. In addition, throwing something onto
the
> wiki,
> > > and
> > > > > > then
> > > > > > > > a few weeks before we'd like to cut a version raising
a
> > > discussion
> > > > > > > > thread on work that has been going on for months already
does
> > not
> > > > > help
> > > > > > > > with the community being able to read, digest, think,
reason
> > and
> > > > > > respond
> > > > > > > > BEFORE it is released.
> > > > > > > >
> > > > > > > > I know `@Experimental` is non-binding on API's or
usage, BUT
> I
> > > > prefer
> > > > > > > > some of the ground work to have been discussed, API's
> validated
> > > > > BEFORE
> > > > > > > > it is released into the wild. I mean this is a PUBLIC
API, so
> > > we'd
> > > > > > > > prefer to get it more correct than the previous one.
> > > > > > > >
> > > > > > > > Maybe it is just me, taking it too serious... Where
I prefer
> > not
> > > > > > release
> > > > > > > > something as close to 95% correct (and discussed).
> > > > > > > >
> > > > > > > > Anyway.. If we want to cut 1.10... and we should...
Let's do
> > so..
> > > > but
> > > > > > > > I'd prefer that more on the correctness on the approach.
> > > > > > > >
> > > > > > > > --Udo
> > > > > > > >
> > > > > > > > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > > > > > > > >> I don't believe we should be including anything
into the
> > Geode
> > > > > > release
> > > > > > > > >> that has not gone through the correct process
of feature
> > > > proposal.
> > > > > > > > >>
> > > > > > > > >> All work under the experimental cluster management
service
> > has
> > > > not
> > > > > > yet
> > > > > > > > >> been approved by the agreed upon RFC process.
> > > > > > > > >>
> > > > > > > > > Udo, I didn't take the RFC process that we agreed
on to be
> a
> > > gate
> > > > > > > keeper,
> > > > > > > > > but rather a way to de-risk work before making
a PR.
> > > > > > > > >
> > > > > > > > >  From the RFC doc in the wiki:
> > > > > > > > >
> > > > > > > > >> When to write an RFC?
> > > > > > > > >>
> > > > > > > > >> Writing an RFC should be entirely voluntary.
There is
> always
> > > the
> > > > > > > option
> > > > > > > > of
> > > > > > > > >> going straight to a pull request. However,
for larger
> > changes,
> > > > it
> > > > > > > might
> > > > > > > > be
> > > > > > > > >> wise to de-risk the risk of rejection of
the pull request
> by
> > > > first
> > > > > > > > >> gathering input from the community. Therefore
it’s up to
> > every
> > > > > > member
> > > > > > > of
> > > > > > > > >> our community to decide themselves when they
want to reach
> > for
> > > > > this
> > > > > > > > tool.
> > > > > > > > >>
> > > > > > > > > If we want to change the role of the RFC process,
that's
> fine
> > > > with
> > > > > > me,
> > > > > > > > but
> > > > > > > > > we should have that discussion first.
> > > > > > > > >
> > > > > > > > > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart
<
> > > > > > > stewart.jared@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> What was missing from the RFC process for
the cluster
> > > management
> > > > > > > > service?
> > > > > > > > >> I saw a [Discuss] thread for it, as well
as a proposal at
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> > > > > > > > >>
> > > > > > > > >> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer
<
> > > udo@apache.com>
> > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >>> I don't believe we should be including
anything into the
> > > Geode
> > > > > > > release
> > > > > > > > >>> that has not gone through the correct
process of feature
> > > > > proposal.
> > > > > > > > >>>
> > > > > > > > >>> All work under the experimental cluster
management
> service
> > > has
> > > > > not
> > > > > > > yet
> > > > > > > > >>> been approved by the agreed upon RFC
process.
> > > > > > > > >>>
> > > > > > > > >>> I don't believe we should be including
this work,
> > > experimental
> > > > or
> > > > > > > > >>> otherwise.
> > > > > > > > >>>
> > > > > > > > >>> --Udo
> > > > > > > > >>>
> > > > > > > > >>> On 7/22/19 4:51 PM, Alexander Murmann
wrote:
> > > > > > > > >>>> Udo, do you mind explaining how the
RFC process comes
> into
> > > > this?
> > > > > > Are
> > > > > > > > >> you
> > > > > > > > >>>> suggesting that we should wait if
an RFC had a target
> > > release
> > > > > > > > attached?
> > > > > > > > >>>>
> > > > > > > > >>>> On Mon, Jul 22, 2019 at 4:47 PM Udo
Kohlmeyer <
> > > udo@apache.com
> > > > >
> > > > > > > wrote:
> > > > > > > > >>>>
> > > > > > > > >>>>> I don't think we need to wait
for this, as there has
> been
> > > no
> > > > > RFC
> > > > > > > > >> process
> > > > > > > > >>>>> followed.
> > > > > > > > >>>>>
> > > > > > > > >>>>> --Udo
> > > > > > > > >>>>>
> > > > > > > > >>>>> On 7/22/19 3:38 PM, Jinmei Liao
wrote:
> > > > > > > > >>>>>> Work is still being planned
to move the cluster
> > management
> > > > > rest
> > > > > > > > >> service
> > > > > > > > >>>>>> under an experimental version
flag and use a geode
> > > property
> > > > to
> > > > > > > turn
> > > > > > > > >> it
> > > > > > > > >>>>>> on/off. I would say we are
ready to cut the geode
> 1.10.0
> > > > after
> > > > > > > that
> > > > > > > > >>> work
> > > > > > > > >>>>> is
> > > > > > > > >>>>>> complete.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> On Mon, Jul 22, 2019 at 3:24
PM Alexander Murmann <
> > > > > > > > >> amurmann@apache.org
> > > > > > > > >>>>>> wrote:
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>> Hi everyone!
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> We released Geode 1.9.0
on April 25th. That's about 3
> > > > months
> > > > > > ago.
> > > > > > > > >> End
> > > > > > > > >>> of
> > > > > > > > >>>>>>> last year we discussed
releasing quarterly. In the
> past
> > > > we've
> > > > > > had
> > > > > > > > >>> about
> > > > > > > > >>>>> a
> > > > > > > > >>>>>>> month between cutting
a release branch and actually
> > > > shipping
> > > > > > our
> > > > > > > > new
> > > > > > > > >>>>> minor.
> > > > > > > > >>>>>>> This means we are already
behind our target release
> > > > cadence.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> What are your thoughts
on cutting a 1.10.0 release
> > branch
> > > > > this
> > > > > > > > week?
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> Would anyone like to
volunteer to be the release
> > manager
> > > > for
> > > > > > > geode
> > > > > > > > >>>>> 1.10.0?
> > > > > > > > >>>>>>> Thank you all!
> > > > > > > > >>>>>>>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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