I would love for GEODE-6399 / PR #3190 to be included in this release. This PR resolves the earlier issues we had delegating dependencies to the geode-all-bom BOM and massively reduces the POMs for each module we publish.
As it is, the published POMs are functional, and I understand that such things are rarely human-inspected, but given that we haven't introduced the <dependencyManagement> into our maven artifacts yet, I'd just as soon have it done right when we do. Not really a show-stopping issue, but it does involve our forward-facing artifacts. On Tue, Feb 19, 2019 at 2:20 PM Sai Boorlagadda <sai.boorlaga...@gmail.com> wrote: > 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! > > >>>>>>>>>>>> > > >
