geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Rhomberg <prhomb...@pivotal.io>
Subject Re: Geode 1.9 Release Manager
Date Thu, 21 Feb 2019 00:12:40 GMT
I would love for GEODE-6399 / PR #3190 to be included in this release.
This PR resolves the earlier issues we had delegating dependencies to the
geode-all-bom BOM and massively reduces the POMs for each module we publish.

As it is, the published POMs are functional, and I understand that such
things are rarely human-inspected, but given that we haven't introduced the
<dependencyManagement> into our maven artifacts yet, I'd just as soon have
it done right when we do.

Not really a show-stopping issue, but it does involve our forward-facing
artifacts.

On Tue, Feb 19, 2019 at 2:20 PM Sai Boorlagadda <sai.boorlagadda@gmail.com>
wrote:

> Thanks Bruce. I will chery-pick this commit onto the new release branch.
>
> On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt <bschuchardt@pivotal.io>
> wrote:
>
> > The fix for Geode-6369 has been pushed to develop.  This needs to go in
> > the 1.9 release as it fixes some serious issues in auto-reconnect
> > including a distributed deadlock.
> >
> > On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
> > > There are about 8[1] issues in JIRA that are in
> > open/in-progress/re-opened
> > > status for 1.9.0.
> > > Can I request all the devs to reflect JIRA with current status?
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
> > >
> > > Sai
> > >
> > > On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > >> Thanks Dave. I keep a note to include Geode Native.
> > >>
> > >> As we are including only a source release for Geode Native
> > >> do we need to create a release branch? Or just tag it?
> > >>
> > >> Though we will eventually be tagging Geode & Geode Examples repos.
> > >> So until it gets released I think as a place holder I can go ahead
> still
> > >> create a release branch for Geode Native?
> > >>
> > >> Sai
> > >>
> > >>
> > >> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <dbarnes@apache.org>
> wrote:
> > >>
> > >>> Sai,
> > >>> The Geode 1.8 release included (for the first time) a source snapshot
> > of
> > >>> the geode-native repo.
> > >>> As far as I know, the same treatment would be in order for v1.9.
> > >>>
> > >>>
> > >>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <
> > bschuchardt@pivotal.io>
> > >>> wrote:
> > >>>
> > >>>> I would like to get GEODE-6369 into the next release but that can
be
> > >>>> done in a cherry-pick after I finish testing.  The changes are
in in
> > >>>> discovery, joining the cluster and in failure detection so they've
> > >>>> needed extensive testing.
> > >>>>
> > >>>> On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> > >>>>> I am planning to cut the1.9 release branch today after merging
this
> > >>>>> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> > >>>>>
> > >>>>> Is there anything other than that I should be aware of?
> > >>>>>
> > >>>>> Here is the list of issues that were requested to be included
into
> > >>> 1.9.
> > >>>>> If there is any plan to merge any of these today let me know
and
> > >>>>> I can cut the branch after that.
> > >>>>>
> > >>>>> GEODE-6334 - CachePerfStats operation count stats may wrap
to
> > negative
> > >>>>> values
> > >>>>>
> > >>>>> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
> > >>> value
> > >>>>> GEODE-6369 - Cache-creation failure after a successful
> auto-reconnect
> > >>>>> causes subsequent NPE
> > >>>>>
> > >>>>> GEODE-6391 - Event IDs must be included in the PartitioneRegion
> > >>> messages
> > >>>>> GEODE-6404 - review use of computeIfAbsent across the code
base
> > >>>>>
> > >>>>>
> > >>>>> (experimental and dropped)
> > >>>>>
> > >>>>> GEODE-6393 - Replace synchronization lock with AtomicReference
for
> > >>>>> InternalLocator
> > >>>>>
> > >>>>>
> > >>>>> -
> > >>>>>
> > >>>>> Sai
> > >>>>>
> > >>>>> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> > >>>> sai.boorlagadda@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I didn't mean blocking a release but the release process
> (including
> > >>>>>> cutting the branch).
> > >>>>>>
> > >>>>>>
> > >>>>>> I thought there was a consensus about strictly cutting
a
> > >>>>>>
> > >>>>>> branch[1] with our new fixed minor release cadence and
> > >>>>>>
> > >>>>>> only allow critical fixes.
> > >>>>>>
> > >>>>>>
> > >>>>>> I assumed that any critical fixes that are allowed onto
the
> > >>>>>>
> > >>>>>> release branch are the ones that are identified on the
branch
> > >>>>>>
> > >>>>>> after it is cut and not the ones that are already known.
> > >>>>>>
> > >>>>>>
> > >>>>>> Correct me if my understanding is wrong.
> > >>>>>>
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> > >>>>>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nnag@pivotal.io>
> > >>> wrote:
> > >>>>>>> I could not find any DISCUSS mails about not blocking
a release.
> I
> > >>> may
> > >>>> be
> > >>>>>>> wrong, I apologize for that but could point me to the
mail /
> > >>>> documentation
> > >>>>>>> about the release management.
> > >>>>>>>
> > >>>>>>> Regards
> > >>>>>>> Naba
> > >>>>>>>
> > >>>>>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > >>>>>>> sai.boorlagadda@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Did we not agreed that we won't be blocking a release
to include
> > >>> fixes
> > >>>>>>> as
> > >>>>>>>> we are in a fixed release schedule?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann
<
> > >>>> amurmann@apache.org
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Usually I am a proponent of cutting a branch
and then fixing
> > >>> things
> > >>>> on
> > >>>>>>>>> there where things are more stable. In this
case we seem to
> have
> > a
> > >>>>>>> large
> > >>>>>>>>> number of fairly serious concerns. Do we think
the cost of
> > putting
> > >>>>>>> this
> > >>>>>>>>> many fixes on develop + the release branch
out-weights the
> > >>> benefit of
> > >>>>>>>> less
> > >>>>>>>>> risk of new issues being introduced?
> > >>>>>>>>>
> > >>>>>>>>> Thoughts?
> > >>>>>>>>>
> > >>>>>>>>> Thank you, Sai for taking over!
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda
<
> > >>>>>>>>> sai.boorlagadda@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I volunteer to be the release manager for
1.9.
> > >>>>>>>>>>
> > >>>>>>>>>> Sai
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander
Murmann <
> > >>>>>>> amurmann@apache.org
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> If there are no other takers, I can
act as release manager
> for
> > >>> 1.9
> > >>>>>>>> and
> > >>>>>>>>>> will
> > >>>>>>>>>>> cut a release branch this week.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander
Murmann <
> > >>>>>>>> amurmann@apache.org
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi everyone!
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> February 1st is approaching rapidly
which means it's almost
> > >>>>>>> time to
> > >>>>>>>>> cut
> > >>>>>>>>>>>> the 1.9 release. Who is interested
in being the release
> > manager
> > >>>>>>> for
> > >>>>>>>>>> 1.9?
> > >>>>>>>>>>>> Thank you!
> > >>>>>>>>>>>>
> >
>

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