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