Thanks Bruce. I will chery-pick this commit onto the new release branch. On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt <bschucha...@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.boorlaga...@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 <dbar...@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 < > bschucha...@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.boorlaga...@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 <n...@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.boorlaga...@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 < > >>>> amurm...@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.boorlaga...@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 < > >>>>>>> amurm...@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 < > >>>>>>>> amurm...@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! > >>>>>>>>>>>> >
