Just tag, I think. On Fri, Feb 15, 2019 at 2:15 PM Sai Boorlagadda <sai.boorlaga...@gmail.com> 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! >>> > >>>>>>>> >>> > >>> >>
