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! > > >>>>>>>> > > >
