geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karen Miller <kmil...@pivotal.io>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Wed, 31 Jul 2019 00:09:46 GMT
Alexander, can you point me at the policy decision for the "critical issue"
rule you mention? I always though it was up
to the release manager.

I want GEODE-7013 fixes in because it is the right thing to do.  Our gfsh
help/hint wasn't working the way we say that it did.
With the fix, it does.  I want either the documentation to match the code,
or I want the code to match the documentation.
The fix in GEODE-7013 changes the code to match the existing documentation,
so we don't have to change the documentation
(which would have needed to be cherry-picked into our 1.10 release branch).


On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols <onichols@pivotal.io> wrote:

> Our "critical issue” rule has the effect that the bar to commit to develop
> is “low”, but the bar to cherry-pick to support branch is “very high”.
>
> Contributors could plan around this disparity more easily if any of the
> following were true:
> - releases were more frequent
> - planned cut date of release branch was announced in advance (rather than
> retroactively)
> - a process existed for making exceptions to the “critical issue” rule
>
> I agree that the proposed SHA looks like a relatively stable branchpoint
> (coming near the end of a nice period of solid green in the pipeline), and
> I acknowledge that fair warning was given a week ago that a branch was
> “coming soon”, but I wonder if there is anything we can do to make the
> rules for what gets in a release and what doesn’t feel a little less
> arbitrary?
>
> -Owen
>
>
> > On Jul 30, 2019, at 11:16 AM, Alexander Murmann <amurmann@apache.org>
> wrote:
> >
> > 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