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: Geode 1.9 Release Manager
Date Fri, 15 Feb 2019 22:15:30 GMT
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