geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Schuchardt <bschucha...@pivotal.io>
Subject Re: Geode 1.9 Release Manager
Date Tue, 19 Feb 2019 21:06:34 GMT
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
View raw message