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