Re: [PROPOSAL] include GEODE-8055 in support/1.13
+1 Go ahead, Jinmei, and cherry-pick the GEODE-8055 fix to the Geode support/1.13 branch. Dave Geode 1.13 release manager On Mon, May 4, 2020 at 10:12 PM Dick Cavender wrote: > +1 > > On Mon, May 4, 2020 at 8:28 PM Owen Nichols wrote: > > > Hi Jinmei, it looks like your commit came in just minutes after the > > support/1.13 branch was cut, but before the email announcing the branch > cut > > was sent. +1 from me to go ahead and bring to support/1.13 on that > basis. > > > > > On May 4, 2020, at 7:43 PM, Jinmei Liao wrote: > > > > > > Yes, there is a user request to reinstate this feature. > > > > > > On Mon, May 4, 2020 at 4:41 PM Anilkumar Gingade > > > wrote: > > > > > >> Since this issue is introduced from 1.7; meaning its present from 1.7 > > time, > > >> can it be added in the next release, is there any strong user/customer > > >> requirement to get this in 1.13. > > >> > > >> -Anil. > > >> > > >> > > >> On Mon, May 4, 2020 at 11:55 AM Jinmei Liao > wrote: > > >> > > >>> I would like to include the fix for GEODE-8055 in the 1.13 branch. > This > > >>> would allow users to use gfsh to create an index on sub regions. > > >>> > > >>> -- > > >>> Cheers > > >>> > > >>> Jinmei > > >>> > > >> > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > >
Re: [PROPOSAL] include GEODE-8055 in support/1.13
Done. Thanks! On Tue, May 5, 2020 at 11:47 AM Dave Barnes wrote: > +1 > Go ahead, Jinmei, and cherry-pick the GEODE-8055 fix to the Geode > support/1.13 branch. > > Dave > Geode 1.13 release manager > > > On Mon, May 4, 2020 at 10:12 PM Dick Cavender > wrote: > > > +1 > > > > On Mon, May 4, 2020 at 8:28 PM Owen Nichols wrote: > > > > > Hi Jinmei, it looks like your commit came in just minutes after the > > > support/1.13 branch was cut, but before the email announcing the branch > > cut > > > was sent. +1 from me to go ahead and bring to support/1.13 on that > > basis. > > > > > > > On May 4, 2020, at 7:43 PM, Jinmei Liao wrote: > > > > > > > > Yes, there is a user request to reinstate this feature. > > > > > > > > On Mon, May 4, 2020 at 4:41 PM Anilkumar Gingade < > aging...@pivotal.io> > > > > wrote: > > > > > > > >> Since this issue is introduced from 1.7; meaning its present from > 1.7 > > > time, > > > >> can it be added in the next release, is there any strong > user/customer > > > >> requirement to get this in 1.13. > > > >> > > > >> -Anil. > > > >> > > > >> > > > >> On Mon, May 4, 2020 at 11:55 AM Jinmei Liao > > wrote: > > > >> > > > >>> I would like to include the fix for GEODE-8055 in the 1.13 branch. > > This > > > >>> would allow users to use gfsh to create an index on sub regions. > > > >>> > > > >>> -- > > > >>> Cheers > > > >>> > > > >>> Jinmei > > > >>> > > > >> > > > > > > > > > > > > -- > > > > Cheers > > > > > > > > Jinmei > > > > > > > > > -- Cheers Jinmei
Re: [DISCUSS] Publish Builds, not Snapshots
I have no current plans on backporting, though it might make the continued Concourse testing of those branches easier. There is a PR about this available: https://github.com/apache/geode/pull/5057 On Thu, Apr 30, 2020 at 9:25 PM Owen Nichols wrote: > It sounds like the only impact is that downstream projects that consume > -SNAPSHOT builds will need to make one small change to their maven config; > downstream projects that consume release versions will be unaffected. So > just let us know when to make that change. > > Anytime soon after support/1.13 is cut would be great to bring this change > to develop. Assuming it goes smoothly on develop, would you envision > backporting to support/1.13 and support/1.12 as well? > > > On Apr 30, 2020, at 8:38 PM, Robert Houghton > wrote: > > > > I don't read any strong negatives to this change. I would like to start > > polishing a PR on this work, unless anyone has strong opposing feelings. > > Does anyone feel that this change requires a VOTE? > > > > On Tue, Apr 28, 2020 at 10:36 AM Jacob Barrett > wrote: > > > >> Probably for a separate discussion but I would opt for a future where > the > >> release manager validates and signs a specific build from produced by > the > >> CI. This takes a lot of error away in the what the release manager > >> currently does, which has resulted in incorrect artifacts being voted > on. > >> > >> In this model the release manager would be certifying a release with > full > >> version number, or whatever we choose for the release version number. > >> > >> Until then the release manager could just use the short number. In > >> Gradle/Maven versioning a version without qualifier is always newer than > >> one with. So 1.13.0 is newer than any 1.13.0-build.123. > >> > >> -Jake > >> > >> > >>> On Apr 28, 2020, at 10:24 AM, Anthony Baker wrote: > >>> > >>> Note that I’m asking about building on my local system. Will the > >> version listed in gradle.properties use the full 1.13.0-build.123 > syntax? > >> How would it get bumped? > >>> > >>> Would a release manager end up using just 1.13.0? Hoping for yes :-) > >>> > >>> Anthony > >>> > On Apr 28, 2020, at 9:24 AM, Robert Houghton > >> wrote: > > @anthony > /develop would say 1.13.0-build.230 (as of this morning). > Once cut, /release/1.13 would say 1.13.0-build.231, and /develop would > switch to 1.14.0-build.1. > > gfsh would return that full value. That is the artifact version. > > On Mon, Apr 27, 2020 at 4:38 PM Anthony Baker > >> wrote: > > > If I build the /develop branch and run `gfsh version` what will it > >> print? > > > > If I build the soon-to-be /release/1.13 branch and run `gfsh version` > >> what > > will it print? > > > > Anthony > > > > > > On 4/27/20, 4:32 PM, "Robert Houghton" > wrote: > > > > The artifact would change from "1.13.0-SNAPSHOT" to > >> "1.13.0-build.123". > > > > > > > > > > > >>> > >> > >> > >
Re: RFC - Logging to Standard Out
I think this could be moved to "In Development" since there is consensus. I created a JIRA for it: https://issues.apache.org/jira/browse/GEODE-8077
