Re: [DISCUSS] - Move gfsh into its own submodule

[Dave Barnes]

+1

On Fri, Nov 22, 2019 at 9:17 AM Kirk Lund  wrote:

> +1 yes!
>
> On Fri, Nov 22, 2019 at 9:15 AM Donal Evans  wrote:
>
> > +1
> >
> > Especially with the new management functionality on the way, this seems
> > like a good idea.
> >
> > On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao  wrote:
> >
> > > +100. Would be a great move.
> > >
> > > On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe 
> wrote:
> > >
> > > > Hello All,
> > > >
> > > > We'd like to propose moving gfsh and all associated commands into its
> > own
> > > > gradle submodule (implicitly thus also producing a separate maven
> > > > artifact). The underlying intent is to decouple geode core from any
> > > Spring
> > > > dependencies.
> > > >
> > > > The proposal is outlined here:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > >
> > > > Please provide feedback for this proposal *on this email thread* and
> > not
> > > in
> > > > the comment section of the proposal page.
> > > >
> > > > The deadline for this proposal will be Monday, December 2.
> > > >
> > > > Thanks in advance for feedback / comments.
> > > >
> > > > --Jens & Patrick
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: Request for addition to 1.11 RC: GEODE-7454: Docs for Cluster Management Service

[Dave Barnes]

Following up: Thanks for incorporating this docs-only change into the
release candidate.
When testing, I realized I need to add a template variable to the config
file to make this work.
Anyone object to me submitting a 1-line change in each of the 2 affected
files?
Again, docs only, no code change.
(The corresponding change has already been incorporated on the 'develop'
branch.)

On Tue, Dec 3, 2019 at 2:49 PM Mark Hanson  wrote:

> Done.
>
> > On Dec 3, 2019, at 9:24 AM, Dave Barnes  wrote:
> >
> > Docs for a feature that's already implemented - no code changes.
> > Can be cherry-picked from the develop branch as-is with no modifications.
> >
> https://github.com/apache/geode/commit/e48f34048c574440ed7e0640f42e9c82d789becb
>
>

Request for addition to 1.11 RC: GEODE-7454: Docs for Cluster Management Service

[Dave Barnes]

Docs for a feature that's already implemented - no code changes.
Can be cherry-picked from the develop branch as-is with no modifications.
https://github.com/apache/geode/commit/e48f34048c574440ed7e0640f42e9c82d789becb

Re: [VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

[Dave Barnes]

Mark - I'll help out with docs -- updating the website, etc.

On Mon, Oct 28, 2019 at 2:00 PM Mark Hanson  wrote:

> Hi All,
>
> Since we need a release manager for 1.11 and no one has volunteered, yet.
> I thought I would volunteer.
>
> Thanks,
> Mark

Re: [VOTE] Apache Geode 1.9.2.RC1

[Dave Barnes]

+1
Downloaded, successfully built Geode and Geode-Native docs form source.

On Tue, Oct 22, 2019 at 2:17 AM Ju@N  wrote:

> +1,
>
> Downloaded and built from source, created two clusters with multiple
> members and verified WAN replication (along with some gateway related
> commands) work properly.
> Best regards.
>
>
> On Mon, Oct 21, 2019 at 8:04 PM Udo Kohlmeyer  wrote:
>
> > +1,
> >
> > Checked that WAR's are generated for geode-web and geode-web-api.
> >
> > Also ran set of examples and tests from Spring Data Geode (Moore), to
> > confirm that it has not broken functionality.
> >
> > --Udo
> >
> > On 10/21/19 8:20 AM, Jens Deppe wrote:
> > > Since the deadline has expired without enough votes, I am going to
> extend
> > > it for another 48(ish) hours until 8am PST, Wednesday , 23rd October.
> > >
> > > Thanks
> > > --Jens
> > >
> > > On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe 
> > wrote:
> > >
> > >> Hello Geode Dev Community,
> > >>
> > >> This is a release candidate for Apache Geode version 1.9.2.RC1.
> > >> Thanks to all the community members for their contributions to this
> > >> release!
> > >>
> > >> Please do a review and give your feedback, including the checks you
> > >> performed.
> > >>
> > >> Voting deadline:
> > >> 3PM PST Sun, October 20 2019.
> > >>
> > >> Please note that we are voting upon the source tag:
> > >> rel/v1.9.2.RC1
> > >>
> > >> Release notes:
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> > >>
> > >> Source and binary distributions:
> > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> > >>
> > >> Maven staging repo:
> > >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> > >>
> > >> GitHub:
> > >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> > >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> > >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> > >>
> > >> Pipelines:
> > >>
> > >>
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> > >>
> > >>
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> > >>
> > >> Geode's KEYS file containing PGP keys we use to sign the release:
> > >> https://github.com/apache/geode/blob/develop/KEYS
> > >>
> > >> Command to run geode-examples:
> > >> ./gradlew -PgeodeReleaseUrl=
> > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> > >> -PgeodeRepositoryUrl=
> > >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> > >> build runAll
> > >>
> > >> Regards
> > >> --Jens
> > >>
> >
>
>
> --
> Ju@N
>

Re: [DISCUSS]: Commit Message Format too Short?

[Dave Barnes]

The Template Checklist is a great reference for the committer who builds
and submits the PR, but I find it of little value as a posted comment for
reviewers of the PR - just takes up a lot of space. As a frequent reviewer,
I like to see:
- A clear and concise title beginning with the ticket number
- Additional details in the initial comments box.
Currently, if the title exceeds the space available, it wraps into the
comment box. It ain't pretty, but it works for those occasions when more
space is needed.

On Tue, Oct 8, 2019 at 8:58 AM Ernest Burghardt 
wrote:

> back to Juan's original point: (I think this was anyway)
> +1 to details and more details on the commit message and if removing
> pedantic guidelines and just using tooling to word wrap will encourage
> better communication via better commit messages
>
> On Tue, Oct 8, 2019 at 8:33 AM Owen Nichols  wrote:
>
> > Apache values people over process.  So I am in favor of removing any
> > “rules” regarding commit messages (except for: must put a colon after the
> > GEODE ticket number!)
> >
> > Guidelines (not rules) can be helpful.  I would like developers reading
> > our commit message guidelines <
> > https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format>
> > to be inspired to "tell the story of your work”, not waste 10 minutes
> > manually reflowing a paragraph because one added word made the first line
> > too long to cat to lp.
> >
> > I think adding a few examples of well-written commit messages to our
> > guidelines would be the best use of that wiki page.
> >
> > -Owen
> >
> > >
> > > On Oct 8, 2019, at 7:54 AM, Juan José Ramos  wrote:
> > >
> > > Hello Alberto,
> > >
> > > It might help to add the reminder to the PR template but, honestly, I
> > don't
> > > think many people is actually paying much attention to that... in fact
> I
> > > recall another email thread from some time ago discussing getting rid
> of
> > > the template altogether :-/.
> > > Cheers.
> > >
> > > On Tue, Oct 8, 2019 at 11:58 AM Alberto Bustamante Reyes
> > >  wrote:
> > >
> > >> I think its a good idea to have an automatic mechanism to reject
> commits
> > >> that exceed a given limit.
> > >> In the previous project I was assigned we used Gerrit instead of
> Github,
> > >> and we had an automatic check to vote -1 if your commit message
> exceeded
> > >> the limit.
> > >>
> > >> Anyway, while this is decided, a quick action could be to add a new
> line
> > >> to the PR template, at least to remember it:
> > >>
> > >> - [ ] Is your commit message length below the limit of 50 characters?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 
> > >> De: Juan José Ramos 
> > >> Enviado: martes, 8 de octubre de 2019 11:32
> > >> Para: dev@geode.apache.org 
> > >> Asunto: Re: [DISCUSS]: Commit Message Format too Short?
> > >>
> > >> Hello Owen,
> > >>
> > >> Yes, I fully agree with you. And just to be clear, I wasn't trying to
> > >> discourage descriptive commit messages, on the contrary, we certainly
> > must
> > >> encourage them at all cost!!. It was decided that we should, however,
> > try
> > >> to keep consistency across all commits and make the subject brief,
> > adding
> > >> the full details within the body of the text; as described in *How to
> > write
> > >> a Git commit message [1], *referenced in our *Commit Message Format
> > >> [2] *article.
> > >> Right now we're not enforcing this rule, there are even some commits
> > >> without the ticket number at the beginning of the commit subject :-/.
> > >> I guess the goal of this thread is to gather some feedback and
> opinions
> > >> from the community to better decide how to proceed: remove the rule,
> > >> increase the maximum amount of characters from 50 to something else in
> > the
> > >> commit message subject, automatically enforce the rule altogether and
> > >> prevent commits that don't follow it, etc.
> > >> Best regards.
> > >>
> > >> [1]: https://chris.beams.io/posts/git-commit/
> > >> [2]:
> > >>
> https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format
> > >>
> > >> On Tue, Oct 8, 2019 at 10:07 AM Owen Nichols 
> > wrote:
> > >>
> > >>> I don’t care how long it is, but knowing that many tools show only
> the
> > >>> first bit, it’s helpful if the message is phrased with the most
> > important
> > >>> words near the beginning.
> > >>>
> > >>> I’d much prefer to encourage rather than discourage descriptive
> commit
> > >>> messages. Even better if all commit messages mentioned more about
> _why_
> > >> the
> > >>> change is being made, not just describe the diff.
> > >>>
> > >>> But most important of all, NEVER forget the colon between the ticket
> > >> number
> > >>> and the rest.  I learned that the hard way :(
> > >>>
> > >>> -Owen
> > >>>
> > >>> On Tue, Oct 8, 2019 at 1:52 AM Ju@N  wrote:
> > >>>
> >  Hello devs,
> > 
> >  I've notice that, lately, not everybody is following the guidelines
> we
> > >>> have
> >  highlighted in our 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Dave Barnes]

The proposal mentions "semi-permanent community release managers".
Assuming that a patch release is simpler than a full release, these patch
releases might serve well as training opportunities for first-time release
managers.
+1 if that's the case.

On Tue, Feb 25, 2020 at 9:29 AM Anthony Baker  wrote:

> Here’s a couple things I’d like to avoid:
>
> 1) Issuing a patch release for every single commit that we back port onto
> a supported minor version.  This seems like a high cost approach.  Of
> course, some issues may be important enough to require that.
>
> 2) Merging a change to develop, and then having to come back weeks later
> and back porting the change to a release branch.  It just seems less
> optimal since I’ll have lost the context on the changes, particularly if
> the cherry-pick is non-trivial.
>
> More comments below.
>
> Anthony
>
>
> > On Feb 24, 2020, at 2:16 PM, Owen Nichols  wrote:
> >
> > Hi Alexander, currently we don’t start a patch release until someone
> proposes a critical fix, which then drives the release (the community may
> propose “extra” fixes to tag along once a release branch is cut).  This
> keeps the process simple, neat and tidy.
> >
> > Another option I hadn’t thought of is to begin collecting “extra” fixes
> proactively on a “dormant” branch, so that when someone finally proposes
> releasing a patch, it will already be primed with a bunch of fixes.  This
> adds complexity (does a different standard apply to bring fixes to a
> dormant branch?  Are release branches separate from support branches?  How
> will committers be able to keep track of what is dormant and what is not?)
> >
>
> Why not just either a) keep the release branch alive? Or b) create a
> support branch from the release tag?
>
> > To implement an N-2 support policy, does it make more sense for Geode to
> make small focused patch releases when needed, or to maintain what amounts
> to “3 develop branches at all times”?
> >
>
> To me, “develop branch” implies ongoing work.  I’m proposing “support
> branch” which means only important changes agreed upon by the project
> community.
>
>
> >
> >> On Feb 24, 2020, at 11:00 AM, Alexander Murmann 
> wrote:
> >>
> >> Thanks for proposing this, Anthony!
> >>
> >>
> >>> I don’t think it’s necessary for this proposal to re-define or clarify
> >>> what constitutes a critical fix; it sounds like the bar would be the
> same
> >>> as the standard we already apply when back-porting to release branches
> >>> (proposal /w justification, and 3 votes in favor).  The only difference
> >>> seems to be that now proposals may list up to three target branches,
> not
> >>> just one.
> >>>
> >> re: Owen
> >> TL;DR: +1 using the same process as we use for merging critical fixes
> >> during an ongoing release seems appropriate.
> >>
> >> Generally merging a fix to a dormant release branch seems less
> problematic
> >> than merging a fix to an active release branch where a merge will reset
> all
> >> release work that has already happened. The cost of merging to a
> >> dormant release branch is much lower than merging to one that's being
> >> actively released. Ideally we could just do a PR to merge fixes back in
> >> most cases. Unfortunately, I believe it's unreasonable to expect that
> >> everyone will be aware at all times what's actively being released and
> >> what's not => Let's pretend we are always shipping these branches.
> >>
> >>
> >>
> >>
> >> On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols 
> wrote:
> >>
> >>> Thank you Anthony for proposing this “N-2” support policy.  It isn’t a
> big
> >>> change, but it is helpful to know that the Geode PMC will now be
> standing
> >>> behind (and ready to vote on) patch releases within a 9-month window.
> >>>
> >>> Overall, this sounds much like how 1.9.1 and 1.9.2 started as community
> >>> proposals, found a release manager, and went on to be successfully
> released.
> >>>
> >>> I don’t think it’s necessary for this proposal to re-define or clarify
> >>> what constitutes a critical fix; it sounds like the bar would be the
> same
> >>> as the standard we already apply when back-porting to release branches
> >>> (proposal /w justification, and 3 votes in favor).  The only difference
> >>> seems to be that now proposals may list up to three target branches,
> not
> >>> just one.
> >>>
> >>> I also don’t think it’s necessary to alter our current process to
> maintain
> >>> a standing "support/x.y" branch.  The proposal states that patch
> releases
> >>> will be “ad-hoc (as needed)”.  Our current process serves this quite
> well:
> >>> we propose a patch release at the time it is needed, then get a release
> >>> manager and create a release branch specifically for that release (e.g.
> >>> release/1.9.2 was created from the rel/v1.9.1 tag), then clean up
> >>> afterwards so no unattended pipelines or branches linger.
> >>>
> >>> The rotating release manager role has been a hallmark of the Geode
> >>> community process, so I hope this proposal 

Re: enable-time-statistics

[Dave Barnes]

Sounds like the caveat could be dropped from the user guide. If we have
consensus on that (am I understanding correctly?), I'll initiate a JIRA
ticket.

On Fri, Jan 10, 2020 at 1:47 PM Jacob Barrett  wrote:

> The biggest impact was in recording all the additional stats in the old
> blocking stats implementation. As of 9.8 the stats internals are mostly
> non-blocking. Enabling time stats has very little of any impact now.
>
> > On Jan 10, 2020, at 12:45 PM, Dan Smith  wrote:
> >
> > I personally wouldn't be too worried about enabling time based
> statistics
> > in production. I think we segregated the time statistics because they do
> > have to call System.nanoTime to measure the elapsed time. At one point in
> > the history with old JDKs they called System.currentTimeMillis, which was
> > really expensive. But now I'm not sure the nanoTime calls really have
> that
> > much of an impact compared to the rest of the processing time.
> >
> > -Dan
> >
> >
> >> On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo 
> wrote:
> >>
> >> Hi geode-dev,
> >>
> >> We have executed some traffic against Geode servers with time-based
> >> statistics enabled and disabled and we didn't see any performance
> >> difference.
> >> The documentation says:
> >>
> >>
> >> If you need time-based statistics, enable that. Time-based statistics
> >> require statistics sampling and archival. Example:
> >>
> >> statistic-sampling-enabled=true
> >> statistic-archive-file=myStatisticsArchiveFile.gfs
> >> enable-time-statistics=true
> >>
> >>
> >> Note: Time-based statistics can impact system performance and is not
> >> recommended for production environments.
> >>
> >>
> >> Do you know on which part this note referring to?
> >>
> >>
> >> Also we tried to enable time statistics on geode native but without
> >> success.
> >>
> >> We change in geode.properties file this parameter to true but didn't get
> >> any additional statistics in statistics archive file.
> >>
> >> Do we need also to change something else to enable it or this is not
> >> working for geode-native?
> >>
> >>
> >> BR,
> >>
> >> Mario
> >>
> >>
>

Re: disable statistic archival

[Dave Barnes]

I'm getting the impression that the user guide could be clearer with regard
to the interactions between

   - enable-statistics
   - statistic-sampling-enabled
   - statistic-archive-file



On Wed, Jan 22, 2020 at 9:30 AM Kirk Lund  wrote:

> Try setting STATISTIC_SAMPLING_ENABLED to false to disable statistic
> sampling.
>
> I think we should delete "An empty string (default) disables statistic
> archival." from the javadocs for STATISTIC_ARCHIVE_FILE to avoid confusion
> and redundancy with STATISTIC_SAMPLING_ENABLED.
>
> See below for the javadocs on both properties.
>
>   /**
>* The static String definition of the "statistic-archive-file"
> property * name="statistic-archive-file"/a>
>* 
>* Description: The file that statistic samples are written to. An
> empty string (default)
>* disables statistic archival.
>* 
>* Default: ""
>*/
>   String STATISTIC_ARCHIVE_FILE = "statistic-archive-file";
>
>   /**
>* The static String definition of the
> "statistic-sampling-enabled" property * name="statistic-sampling-enabled"/a>
>* 
>* Description: "true" causes the statistics to be sampled
> periodically and operating
>* system statistics to be fetched each time a sample is taken. "false"
> disables sampling which
>* also disables operating system statistic collection. Non OS statistics
> will still be recorded
>* in memory and can be viewed by administration tools. However, charts
> will show no activity and
>* no statistics will be archived while sampling is disabled. Starting in
> 7.0 the default value
>* has been changed to true. If statistic sampling is disabled it will
> also cause various metrics
>* seen in gfsh and pulse to always be zero.
>* 
>* Default: "true"
>* 
>* Allowed values: true|false
>*/
>   String STATISTIC_SAMPLING_ENABLED = "statistic-sampling-enabled";
>
> On Tue, Jan 21, 2020 at 1:06 AM Mario Kevo  wrote:
>
> > Hi,
> >
> > We are trying to disable archiving statistic in the file by providing
> > empty string to --statistic-archive-file. This option doesn't work.
> > From the documentation it should work:
> > The file to which the running system member writes statistic samples. For
> > example: “StatisticsArchiveFile.gfs”. An empty string disables archiving.
> > I opened ticket(GEODE-7714<
> > https://issues.apache.org/jira/browse/GEODE-7714>) and try to fix it,
> but
> > without success.
> >
> > As alter runtime command update properties and cache, it checks if any of
> > these parameters change, but if we set this property to an empty string
> it
> > failed with message
> > Please provide a relevant parameter(s).
> > We can change for this parameter that it can be an empty string but how
> > this command works, it goes over all parameters and checks if it is
> > changed. In that case if we provide something like
> > alter runtime --member=server it will be successiful but shouldn't as we
> > didn't provide any parameter.
> >
> > So the proposal is that we need to add a new parameter called
> > --statistic-archiving-enabled  which can be true or false. In case it is
> > true we need to provide also --statistic-archive-file.
> >
> > Any thougths?
> >
> > BR,
> > Mario
> >
> >
>

Request for Confluence edit permissions

[Dave Barnes]

This is a request for permission to edit the Apache Geode Wiki on
Confluence using my Apache credentials:
  Username: dbarnes
  Email: dbar...@apache.com
I've been using another login to access confluence, but I'd like to be able
to do it with my Apache identity.
Thanks,
Dave Barnes
(committer & PMC member)

Request for Docker Hub permissions

[Dave Barnes]

Please grant me permission to upload Apache Geode artifats to Docker hub
using my ID: dbarnes97. Thanks!

Re: [VOTE] Apache Geode 1.11.0.RC4

[Dave Barnes]

+1 Checked geode-native
  - Windows build succeeded
  - docs builds succeeded


On Thu, Dec 26, 2019 at 2:00 PM Anthony Baker  wrote:

> +1
>
> Checked:
>
> - Signatures are good
> - SHA’s are good
> - geode, geode-native builds from source
> - reviewed dependency changes
>
> Fix for next release:
>
> - Include the geode-benchmarks source code with the release artifacts.
> - Update geode-assembly/src/main/dist/LICENSE to remove obsolete
> references to:
> paranamer
> scala-reflect
> scala-library
>
> Anthony
>
>
> > On Dec 20, 2019, at 2:46 PM, Mark Hanson  wrote:
> >
> > Subject: [VOTE] Apache Geode 1.11.0.RC4
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.11.0.RC4.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback, including the checks you
> performed.
> >
> > Voting deadline:
> > 3PM PST Wed, December 26 2019.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.11.0.RC4
> >
> > Release notes:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC4/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1064
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.11.0.RC4
> > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC4
> > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC4
> >
> > Pipelines:
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC4
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1064
> build runAll
> >
> > Regards
> > Mark Hanson
> >
>
>

Re: [DISCUSS] abandon branch protection rules

[Dave Barnes]

@Jacob Barrett  @Robert Houghton  I
have an interest in expediting docs-only PRs and would be interested in
participating in a break-out discussion (or at least reviewing the
conclusions).

On Mon, Dec 30, 2019 at 9:15 AM Robert Houghton 
wrote:

> @Jacob Barrett  I have some ideas on this. Want to
> look at in on Thursday with me?
>
> On Sat, Dec 28, 2019 at 5:28 AM Jacob Barrett  wrote:
>
> > Let’s find a way to get the ci, docs, and other directories not effected
> > by tests out of this testing hold.
> >
> > > On Dec 27, 2019, at 3:23 PM, Nabarun Nag  wrote:
> > >
> > > Please maintain the branch protection rules.
> > > Waiting for reviews and Unit tests to pass does not stifle
> productivity,
> > > but prevents us from making mistakes that are detrimental to the entire
> > > community. If I am not mistaken, we still have pushed code which broke
> > > builds and regressions. I would suggest not removing but improving /
> add
> > > ons to the checks to prevent such issues from happening again.
> > >
> > > Also, personally I feel that CI code can separated out of geode code
> base
> > > as they have no tests to run and they can circumvent the unit test pass
> > > criteria.
> > >
> > > I would just like to say that fixing tests is all of our
> responsibility,
> > > not a particular group of developers.
> > >
> > > Regards
> > > Naba
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> On Fri, Dec 27, 2019 at 3:05 PM Jason Huynh 
> wrote:
> > >>
> > >> Just to add more flavor to my previous response... I currently have a
> PR
> > >> open that modified a method signature that touched a few WAN tests.
> It
> > was
> > >> a simple change, removing an unused parameter.  StressNewTest failed
> > and I
> > >> had to spend another day figuring out 10 or so different failures.  A
> > waste
> > >> of time?  Maybe..  At first, I wasn't going to continue, but after
> > trying a
> > >> few things, it looks like the tests installed a listener that was
> > hampering
> > >> other tests.  At the end (soon once it gets reviewed/merged), we end
> up
> > >> with a Green PR and hopefully have unblocked others on these specific
> > tests
> > >> in the future.
> > >>
> > >>> On Fri, Dec 27, 2019 at 2:58 PM Jason Huynh 
> wrote:
> > >>>
> > >>> I feel the frustration at times, but I do also think the ci/pipelines
> > are
> > >>> improving, breaking less often.  I'm ok with the way things are for
> the
> > >>> moment
> > >>>
> > >>> On Fri, Dec 27, 2019 at 1:47 PM Owen Nichols 
> > >> wrote:
> > >>>
> >  In October we agreed to require at least 1 reviewer and 4 passing PR
> >  checks before a PR can be merged.  Now that we’re tried it for a few
> >  months, do we like it?
> > 
> >  I saw some strong opinions on the dev list recently:
> > 
> > > Changes to the infrastructure to flat out prevent things that
> should
> > >> be
> >  self policing is annoying. This PR review lock we have had already
> > cost
> > >> us
> >  valuable time waiting for PR pipelines to pass that have no
> relevance
> > to
> >  the commit, like CI work. I hate to see process enforced that keeps
> us
> > >> from
> >  getting work done when necessary.
> > 
> > 
> >  and
> > 
> > > I think we're getting more and more bureaucratic in our process and
> >  that it stifles productivity.  I was recently forced to spend three
> > days
> >  fixing tests in which I had changed an import statement before they
> > >> would
> >  pass stress testing.  I'm glad the tests now pass reliably but I was
> > >> very
> >  frustrated by the process.
> > 
> > 
> >  Just wondering if others feel the same way.  Is it time to make some
> >  changes?
> > 
> >  -Owen
> > >>>
> > >>>
> > >>
> >
>

Re: Website refresh (was Re: [DISCUSS] Adding Google Analytics to our website)

[Dave Barnes]

@alberto A great idea - others feel the same: 
https://issues.apache.org/jira/browse/GEODE-2942

On 4/9/20, 2:31 AM, "Alberto Bustamante Reyes" 
 wrote:

It would be great if the new webpage could include a search button for the 
user guide.

BR/

Alberto B.

Re: Reconfiguring our notifications and more

[Dave Barnes]

+1


On 4/21/20, 9:09 AM, "Joris Melchior"  wrote:

+1

From: Anthony Baker 
Sent: April 21, 2020 11:54 AM
To: dev@geode.apache.org 
Subject: Reconfiguring our notifications and more

I’d like a quick round of feedback so we can stop the dev@ spamming [1].

ASF has implemented a cool way to give projects control of lots of things 
[2].  In short, you provide a .asf.yml in each and every GitHub repo to control 
lots of interesting things.  For us the most immediately relevant are:

notifications:
  commits: comm...@geode.apache.org
  issues:  iss...@geode.apache.org
  pullrequests:  notificati...@geode.apache.org
  jira_options: link label comment

I’d like to commit this to /develop and cherry-pick over to /master ASAP.  
Later on we can explore the website and GitHub sections.  Let me know what you 
think.

Anthony


[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-20156data=02%7C01%7Cdaveba%40vmware.com%7Ca78a7e9d08a7453e526f08d7e60e5bac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230821655352712sdata=xf%2BchZqfCwLoOm32dLRX%2F0zXhXYG2IcSOPMIR9jiYOw%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINFRA%2F.asf.yaml%2Bfeatures%2Bfor%2Bgit%2Brepositories%23id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositoriesdata=02%7C01%7Cdaveba%40vmware.com%7Ca78a7e9d08a7453e526f08d7e60e5bac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230821655352712sdata=ydVrMeNM%2B1HP%2FsgCXd7tFDLjkPJ1%2FBZLyZpMnEEZil8%3Dreserved=0

Re: [VOTE] Apache Geode 1.12.0.RC4

[Dave Barnes]

+1
Successfully built User Guide with the provided Docker-based toolset.
Successfully built javadocs.

On Fri, Mar 27, 2020 at 2:56 PM Dan Smith  wrote:

> +1
>
> Ran my release check
> https://github.com/upthewaterspout/geode-release-check
>
> -Dan
>
> On Fri, Mar 27, 2020 at 1:33 PM John Blum  wrote:
>
> > SDG continues to build with the Apache Geode 1.12.0 RC4 bits.
> >
> > https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/
> > https://github.com/spring-projects/spring-data-geode/commits/master-next
> >
> > +1
> >
> >
> > On Fri, Mar 27, 2020 at 1:23 PM Anthony Baker  wrote:
> >
> > > +1
> > >
> > > Things I checked:
> > > - expected files present
> > > - hashes and signatures present and valid
> > > - geode, geode-benchmarks, and geode-examples build from source
> > > - no binaries present in source distributions
> > > - verified that geode source and binary distributions have the correct
> > > SHA's
> > > - able to create a cluster and do region operations using gfsh
> > > - brief license review, no Cat X dependencies found
> > >
> > > Nitpicking:
> > >
> > > 1) Let's be consistent with names of source distribution and
> extensions.
> > > 2) NOTICE file copyright date needs to be updated for -native,
> > > -benchmark, -examples.
> > > 3) Some of the version numbers in LICENSE need to updated to match,
> > > also need to add asm-5.0.4.jar
> > >
> > > Anthony
> > >
> > > On Fri, Mar 27, 2020 at 11:37 AM Ernest Burghardt <
> eburgha...@pivotal.io
> > >
> > > wrote:
> > > >
> > > > Hello Geode Dev Community,
> > > >
> > > > This is a release candidate for Apache Geode version 1.12.0.RC4.
> > > > Thanks to all the community members for their contributions to this
> > > release!
> > > >
> > > > Please do a review and give your feedback, including the checks you
> > > > performed.
> > > >
> > > > Voting deadline:
> > > > 3PM PST Mon, March 30, 2020.
> > > >
> > > > Please note that we are voting upon the source tag:
> > > > rel/v1.12.0.RC4
> > > >
> > > > Release notes:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
> > > >
> > > > Source and binary distributions:
> > > > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4/
> > > >
> > > > Maven staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachegeode-1068
> > > >
> > > > GitHub:
> > > > https://github.com/apache/geode/tree/rel/v1.12.0.RC4
> > > > https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC4
> > > > https://github.com/apache/geode-native/tree/rel/v1.12.0.RC4
> > > > https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC4
> > > >
> > > > Pipelines:
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
> > > >
> > > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > > https://github.com/apache/geode/blob/develop/KEYS
> > > >
> > > > Command to run geode-examples:
> > > > ./gradlew -PgeodeReleaseUrl=
> > > > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4
> > > > -PgeodeRepositoryUrl=
> > > >
> https://repository.apache.org/content/repositories/orgapachegeode-1068
> > > > build runAll
> > > >
> > > > Regards
> > > > Ernie Burghardt
> > >
> >
> >
> > --
> > -John
> > Spring Data Team
> >
>

Re: Switching default branch in .net core repo

[Dave Barnes]

+1
Dave

On 4/23/20, 8:29 AM, "Karen Miller"  wrote:

+1
Karen


On Thu, Apr 23, 2020 at 8:14 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Thu, Apr 23, 2020, 8:05 AM Anthony Baker  wrote:
>
> > Please do, this will match our default approach to development
> > (gitflow-ish).
> >
> > +1
> >
> > Anthony
> >
> >
> > > On Apr 23, 2020, at 7:35 AM, Blake Bender  wrote:
> > >
> > > Good morning,
> > >
> > > We created a repo yesterday for the .net core client work, and the
> > default
> > > branch out of the gate is set to master.  I'd like to switch it to
> > develop,
> > > like the rest of the Geode repos, which apparently requires a quick
> > > heads-up and a couple of +1s to go ahead with.  So... is everyone okay
> > with
> > > this change?
> > >
> > > Thanks,
> > >
> > > Blake
> >
> >
>

[ANNOUNCE] Geode 1.13 support branch coming soon

[Dave Barnes]

The project's time-based schedule targets the first Monday after May 1 for
cutting the support branch.
So, we're planning to cut the Geode 1.13 support branch on Monday, May 4,
2020.

Only critical fixes will be allowed once the support branch has been
created, so do what you can to make the develop branch as stable as
possible before Monday.

Thanks,
Dave

Docker Hub access request

[Dave Barnes]

This is a request for access to upload Apache Geode artifacts to Docker Hub.
My Docker Hub ID is 'dbarnes97'.
Thanks,
Dave Barnes
dbar...@apache.org

Request for Apache Geode release management permissions

[Dave Barnes]

This is a request for bulk modification permissions and admin permissions on 
the Geode project.
Thanks,
Dave Barnes
dbar...@apache.org <mailto:dbar...@apache.org>

Request for Concourse permissions

[Dave Barnes]

This is a request for permissions to log in and create pipelines for Apache 
Geode (https://concourse.apachegeode-ci.info/ 
<https://concourse.apachegeode-ci.info/>).
Thanks,
Dave Barnes
dbar...@apache.com <mailto:dbar...@apache.com>
Github acct ID: davebarnes97

Geode support/1.13 created

[Dave Barnes]

We have created a new support branch for Apache Geode 1.13.0 - support/1.13.
We hope to make a final release in about a month. Please focus your
acceptance testing
on this branch and raise any concerns in the next few weeks.
After some quiet period, we will package a release candidate and present it
for a vote.
Cheers,
Dave

[DISCUSS] Geode 1.13 support branch planning

[Dave Barnes]

It's time to prepare for cutting the Geode 1.13 support branch.
Think about what you'd like to contribute, whip it into shape, and check it
into develop. We'll assess our position on Thursday, April 30, 2020, and
see if cutting the branch is feasible at that time.
Please raise any concerns to the community on this [DISCUSS] thread.
Thanks,
Dave Barnes
Geode 1.13 Release Manager

Re: [DISCUSS] preparing for Geode 1.13.0 release

[Dave Barnes]

I'm willing.

On 4/22/20, 11:43 AM, "Owen Nichols"  wrote:

Geode is scheduled to cut support/1.13 on May 4, as per the quarterly 
release schedule approved [1] in 2018 and affirmed in last month’s “Shipping 
patch releases” RFC [2].

Please volunteer if you are interested in serving as Release Manager for 
Geode 1.13.0.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F8626f7cc73b49cc90129ec5f6021adab3815469048787032935bfc1e%2540%253Cdev.geode.apache.org%253Edata=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047185914sdata=%2BC7sDyrQloYd%2F4UxmBPEXvDKmeKHXzKV6rxPdghbZIE%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FShipping%2Bpatch%2Breleasesdata=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047190906sdata=CAMNC6g7u9GconPgjQF1Qvk90EIFvPvQ449jHjitRIY%3Dreserved=0

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Dave Barnes]

..and 1.12.


On Mon, May 11, 2020 at 6:09 PM Dave Barnes  wrote:

> OK, Jinmei. Three of those plus-ones is the magic minimum.
> Please add your change to 1.13.
> Dave
>
>
> On Mon, May 11, 2020 at 4:20 PM Donal Evans  wrote:
>
>> +1
>>
>> On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
>> wrote:
>>
>> > +1
>> >
>> > On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
>> >
>> > > https://issues.apache.org/jira/browse/GEODE-8091
>> > >
>> > > We've had users that were trying to use the
>> > > "--load-cluster-configuration-from-dir=true" when starting up a
>> locator
>> > > with a security manager and came across this failure on Geode1.12 and
>> > would
>> > > this to be fixed. Can I get a few +1s to port this back to the support
>> > > branches?
>> > >
>> > >
>> > > --
>> > > Cheers
>> > >
>> > > Jinmei
>> > >
>> >
>>
>

Re: [PROPOSAL] include GEODE-8073 in Geode 1.13 support branch

[Dave Barnes]

OK, Eric, looks like you have the 3 votes needed - go ahead and add the fix
to support/1.13.

Dave


On Wed, May 6, 2020 at 11:43 AM Xiaojian Zhou  wrote:

> +1
> This bug reproduced again in today's regression. It's better to backport to
> 1.13.
>
> On Wed, May 6, 2020 at 11:42 AM Jinmei Liao  wrote:
>
> > +1
> >
> > On Wed, May 6, 2020 at 11:40 AM Owen Nichols 
> wrote:
> >
> > > +1 to fix this NPE on support/1.13 and also support/1.12
> > >
> > > > On May 6, 2020, at 11:19 AM, Eric Shu  wrote:
> > > >
> > > > GEODE-8073
> > >
> > >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [PROPOSAL] include GEODE-8055 in support/1.13

[Dave Barnes]

+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] Merge PR 5103 (GEODE-8083) to support/1.13

[Dave Barnes]

I usually wait for that third +1 to show up. But since it's slow in coming, 
I'll deliver it myself.
+1
Go for it, Robert.

On 5/12/20, 4:17 PM, "Donal Evans"  wrote:

+1 Having parity between develop and support branches in terms of
checks/tests seems like a sensible idea.

On Tue, May 12, 2020 at 4:05 PM Owen Nichols  wrote:

> I see that ApiChecker PR Check <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F156385data=02%7C01%7Cdaveba%40vmware.com%7Ccfaacff8634648109e4e08d7f6cab242%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249222753597209sdata=Wn%2F%2B%2F7NP4rlxMT7w8HC%2BPqKoTIRysEx3p7RMupQ8dV4%3Dreserved=0>
 is passing for 1.13
> so it’s a +1 from me!
>
> > On May 12, 2020, at 3:57 PM, Robert Houghton 
> wrote:
> >
> > This is a squash of GEODE-8083 and 8087, to bring the Java  API
> comparison
> > jobs from Gradle and Concourse to the support branch. Currently runs
> > cleanly from my terminal, and has been green on develop for a week or 
so.
> >
> > @Dave Barnes  , as release manager, what say you?
>
>

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Dave Barnes]

OK, Jinmei. Three of those plus-ones is the magic minimum.
Please add your change to 1.13.
Dave


On Mon, May 11, 2020 at 4:20 PM Donal Evans  wrote:

> +1
>
> On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
> wrote:
>
> > +1
> >
> > On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
> >
> > > https://issues.apache.org/jira/browse/GEODE-8091
> > >
> > > We've had users that were trying to use the
> > > "--load-cluster-configuration-from-dir=true" when starting up a locator
> > > with a security manager and came across this failure on Geode1.12 and
> > would
> > > this to be fixed. Can I get a few +1s to port this back to the support
> > > branches?
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: Discussion - Change Public API Before Initial Release

[Dave Barnes]

Plenty of votes, go ahead, Jake, and add this to the support/1.13 branch.

On Mon, May 11, 2020 at 8:36 AM Joris Melchior  wrote:

> +1
> 
> From: Jacob Barrett 
> Sent: May 8, 2020 21:26
> To: dev@geode.apache.org 
> Subject: Discussion - Change Public API Before Initial Release
>
> Hey Ya’ll,
>
> We have a new API going into 1.13 that has an inconsistency I want to
> address before we are stuck with it. The class SniSocketFactory should be
> renamed SniProxySocketFactory. The class in question produces objects of
> type SniProxySocket. An "SNI socket" isn’t a thing but an SNI proxy is a
> thing. The factory class that produces proxy socket factories (yes a meta
> factory) ProxySocketFactories uses the “ProxySocket” name as well. It fells
> very inconsistent with all the other classes that make up with API for
> SniSocketFactory to not have a proxy in it and be called
> SniProxySocketFactory.
>
> To be very clear, this API has not made it out of development yet but is
> in the 1.13 release branch. Can I get a few thumbs up to open an ticket and
> pick it into the 1.13 release branch before it goes out?
>
> Thanks,
> Jake
>
>

Re: Proposal to bring GEODE-8016 to support branches

[Dave Barnes]

Looks good, Owen. Go ahead and add this to 1.13.

On Mon, May 11, 2020 at 9:49 AM Robert Houghton 
wrote:

> Yes please! +1
>
> On Mon, May 11, 2020 at 2:46 AM Darrel Schneider 
> wrote:
>
> > +1
> >
> > On Sun, May 10, 2020 at 10:05 PM Dick Cavender 
> > wrote:
> >
> > > +1
> > >
> > > On Sat, May 9, 2020 at 6:42 PM Owen Nichols 
> wrote:
> > >
> > > > Last week develop was successfully migrated from publishing -SNAPSHOT
> > to
> > > > publishing -build.nnn, as discussed on the dev list.
> > > >
> > > > I propose that we bring the same change to support/1.13 and
> > support/1.12
> > > > for consistency.  This will allow downstream projects to change over
> > the
> > > > new model “everywhere" rather than having to maintain support for
> both
> > > ways
> > > > and constantly try to remember which branches do it which way.
> > > >
> > > > The specific changes to be cherry-picked from develop are a4c8b <
> > > >
> > >
> >
> https://github.com/apache/geode/commit/a4c8b9ed8bbea584f798164fa5308d236e9b6048
> > > >
> > > > and 39c52 <
> > > >
> > >
> >
> https://github.com/apache/geode/commit/39c522e340196cb30d55d81d93c63028938cd782
> > > >.
> > > > I have prepared PR #5089 
> > for
> > > > support/1.13 and PR #5090  >
> > > for
> > > > support/1.12 due to the version number differences on each branch.
> > >
> >
>

Re: Proposal to bring GEODE-8068 to support/1.13

[Dave Barnes]

Go ahead, Patrick, and add this to 1.13.

On Mon, May 11, 2020 at 8:36 AM Joris Melchior  wrote:

> +1
> 
> From: Patrick Johnson 
> Sent: May 8, 2020 17:40
> To: dev@geode.apache.org 
> Subject: Proposal to bring GEODE-8068 to support/1.13
>
> I’d like to bring GEODE-8068 to support/1.13. This commit reverts two
> prior commits (GEODE-8033 and GEODE-8044). GEODE-8033 and GEODE-8044
> introduced an experimental feature that is useless in its current state and
> has already been redesigned, so there is no reason for it to go out with
> 1.13.
>
> Regards,
> Patrick
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Dave Barnes]

Looks like you have the votes, Juan.
Go ahead and contribute this fix to support/1.13 and support/1.12.
Thanks,
Dave
Geode 1.13 release manager

On Thu, May 7, 2020 at 10:44 AM Eric Shu  wrote:

> +1
>
>
> On Thu, May 7, 2020 at 10:22 AM Jianxia Chen  wrote:
>
> > +1
> >
> > On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
> >
> > > Hello devs,
> > >
> > > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> > > *support/1.13* branches.
> > > The bug was introduced in Geode 1.8.0 and, long story short, prevents
> > > locators from gracefully shutting down whenever a rebalance operation
> is
> > > launched from gfsh (doesn't matter whether the rebalance is successful
> or
> > > not).
> > > The fix has been merged into develop through commit
> > > d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> > > Best regards.
> > >
> > > [1]: https://issues.apache.org/jira/browse/GEODE-8071
> > > [2:]
> > >
> > >
> >
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
> > >
> > > --
> > > Ju@N
> > >
> >
>

Apache Geode board report (DRAFT FOR YOUR REVIEW)

[Dave Barnes]

Please respond with changes & additions by COB Friday, May 8.
See the "bragging points" at the bottom.  Publish and Prevail, y'all!
Thanks,
Dave

## Description:
The mission of Apache Geode is the creation and maintenance of software
related
to a data management platform that provides real-time, consistent access to
data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease)
226 issues closed in JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic
disruption to our community's work routines, we feel these figures,
though lower than those of the previous reporting period, reveal
an engaged and productive development community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31
 This release included improvements to the management REST API,
 .NET and C++ native clients, client/server security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced
 upticks in discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though
 down 16% and 26%, respectively, from the previous quarter. Points of
 emphasis included error recovery improvements, API extensions, and
 compatibility to accommodate containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article
entitled "Apache Geode as a remote Gradle Build Cache"
(
https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html
).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b)
along with an accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March
entitled "Geode Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3),
and another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused
PdxTypes from an Apache Geode Distributed System"
(
https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34
).

Re: [PROPOSAL] Bring GEODE-8100 to support branches

[Dave Barnes]

+ 0.5
Good material! I'm in favor of incoporating this doc update in the 1.13 support 
branch, but would like an opportunity to edit for a few proof-readerish items 
that caught my eye. Will submit a PR today for your review, Jinmei. Thanks for 
your contribution!

On 2020/05/20 14:09:05, Joris Melchior  wrote: 
> More documentation is good!
> 
> +1
> 
> From: Jinmei Liao 
> Sent: May 19, 2020 14:26
> To: geode 
> Subject: [PROPOSAL] Bring GEODE-8100 to support branches
> 
> This is to update documentation to better explain the Cluster management
> service and various geode/system properties that control the behavior of
> it. It also provides more usage examples in the documentation. There is no
> product code change in this, but tt would be helpful to the users who would
> like to understand Cluster management service more.
> 
> --
> Cheers
> 
> Jinmei
> 

Re: [PROPOSAL] bring GEODE-8131 PR to support branches

[Dave Barnes]

We have a quorum, Bruce, so go ahead and add this fix to 1.13 and other support 
branches, as appropriate.
Thanks,
Dave

On 2020/05/19 15:53:28, Bruce Schuchardt  wrote: 
> While investigating a distributed hang we discovered that the alerting system 
> was blocking the logging of critical information that would have helped 
> diagnose the issue.  This PR modifies the logging of this information to 
> first log it at “info” level and then at “fatal” level so that in the future 
> we get this critical information.
> 
>  
> 
> https://github.com/apache/geode/pull/5132
> 
>  
> 
> 

Re: [PROPOSAL] Bring GEODE-8100 to support branches

[Dave Barnes]

OK, Jinmei - we have enough approvals.

Go ahead and add this improvement to support/1.13. If it's appropriate for 
other support branches (I'm not sure in this case) add it to those, too.

Thanks,
Dave

On 2020/05/20 21:45:33, Karen Miller  wrote: 
> +1 for including this documentation in the 1.13 release
> 
> 
> On Wed, May 20, 2020 at 2:31 PM Dave Barnes  wrote:
> 
> > Edit completed, reviewed, and committed.
> >
> > +1 for including this in the 1.13 support branch.
> >
> > On 2020/05/20 16:54:09, Dave Barnes  wrote:
> > > + 0.5
> > > Good material! I'm in favor of incoporating this doc update in the 1.13
> > support branch, but would like an opportunity to edit for a few
> > proof-readerish items that caught my eye. Will submit a PR today for your
> > review, Jinmei. Thanks for your contribution!
> > >
> > > On 2020/05/20 14:09:05, Joris Melchior  wrote:
> > > > More documentation is good!
> > > >
> > > > +1
> > > > 
> > > > From: Jinmei Liao 
> > > > Sent: May 19, 2020 14:26
> > > > To: geode 
> > > > Subject: [PROPOSAL] Bring GEODE-8100 to support branches
> > > >
> > > > This is to update documentation to better explain the Cluster
> > management
> > > > service and various geode/system properties that control the behavior
> > of
> > > > it. It also provides more usage examples in the documentation. There
> > is no
> > > > product code change in this, but tt would be helpful to the users who
> > would
> > > > like to understand Cluster management service more.
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> 

Re: [PROPOSAL] Bring GEODE-8100 to support branches

[Dave Barnes]

Edit completed, reviewed, and committed.

+1 for including this in the 1.13 support branch.

On 2020/05/20 16:54:09, Dave Barnes  wrote: 
> + 0.5
> Good material! I'm in favor of incoporating this doc update in the 1.13 
> support branch, but would like an opportunity to edit for a few 
> proof-readerish items that caught my eye. Will submit a PR today for your 
> review, Jinmei. Thanks for your contribution!
> 
> On 2020/05/20 14:09:05, Joris Melchior  wrote: 
> > More documentation is good!
> > 
> > +1
> > 
> > From: Jinmei Liao 
> > Sent: May 19, 2020 14:26
> > To: geode 
> > Subject: [PROPOSAL] Bring GEODE-8100 to support branches
> > 
> > This is to update documentation to better explain the Cluster management
> > service and various geode/system properties that control the behavior of
> > it. It also provides more usage examples in the documentation. There is no
> > product code change in this, but tt would be helpful to the users who would
> > like to understand Cluster management service more.
> > 
> > --
> > Cheers
> > 
> > Jinmei
> > 
> 

Geode 1.13: What is the status of "experimental" features?

[Dave Barnes]

Three features are listed as “Experimental” in Geode 1.12. Has their status 
changed for 1.13?
- Cluster Management Service: 
https://geode.apache.org/docs/guide/112/configuring/running/cluster-management-service.html
 

- Redis Adapter: 
https://geode.apache.org/docs/guide/112/tools_modules/redis_adapter.html 

- Automated Rebalancing of Partitioned Region Data: 
https://geode.apache.org/docs/guide/112/developing/partitioned_regions/automated_rebalance.html
 


Each carries a note in the user guide stating “Note: This feature is 
experimental and is subject to change in future releases of Apache Geode.”
If I don’t hear otherwise today, the note will remain in place for 1.13.

Thanks,
Dave

Re: [PROPOSAL]: GEODE-8150 into support/1.13

[Dave Barnes]

Please proceed with the proposed merge, Juan.
Thanks,
Dave

On 2020/05/21 16:15:59, Udo Kohlmeyer  wrote: 
> +1..
> On May 21, 2020, 8:12 AM -0700, Ju@N , wrote:
> Hello devs,
> 
> I'd like to propose bringing *GEODE-8150 [1] *to the *support/1.13* branch.
> The ticket is basically to revert the upgrade of the *classgraph* [2]
> library, we found some performance issues that are not addressed even when
> using the latest released version, the full details can be seen in the
> ticket.
> The fix has been merged into develop through commit
> 07bf3dd827f29a5deb8619f79203d94847a1a823 [3].
> Best regards.
> 
> [1]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8150=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567034068=lQ8z8eamQCEzKNwJal0W0k%2B5vjJWguzL8M7vrPPfQhQ%3D=0
> [2]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fclassgraph%2Fclassgraph=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567044068=vZzkQPvUe7vw2iMxt79rd4cTh6dAjesbrqy8urNVOlA%3D=0
> [3]:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2F07bf3dd827f29a5deb8619f79203d94847a1a823=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567044068=iuR%2FW3bNjI7LvDlbvo1vxLyoGwp8IS4GyDYsWb%2FuabM%3D=0
> 
> --
> Ju@N
> 

Re: Proposal to backport GEODE-8167

[Dave Barnes]

Please add this change to support/1.13, Owen.
Thanks,
Dave

On 2020/05/21 16:19:49, Dick Cavender  wrote: 
> +1
> 
> On Thu, May 21, 2020 at 8:57 AM Ju@N  wrote:
> 
> > +1
> >
> > On Thu, 21 May 2020 at 16:53, Anthony Baker  wrote:
> >
> > > +1
> > >
> > > > On May 21, 2020, at 8:51 AM, Owen Nichols  wrote:
> > > >
> > > > Some automated scans have flagged Geode Pulse as potentially containing
> > > “high" security vulnerability CVE-2020-5407.
> > > >
> > > > Analysis shows that this saml vulnerability is not applicable to Geode
> > > Pulse.
> > > >
> > > > It is low risk to bump the spring-security dependency to the latest
> > > version to avoid false positives in automated scans.  This change is
> > > already on develop and all tests have passed.  It would be nice to
> > include
> > > this in 1.13.
> > > >
> > > > -Owen
> > >
> > >
> >
> > --
> > Ju@N
> >
> 

[DISCUSS] Someone to update 3rd-party libraries used by Geode

[Dave Barnes]

Hello Apache Geode Community,
We need a volunteer to update the 3rd-party libraries used by Geode. This
consists of going through the libraries we depend on and updating each to
the latest version that works with our code.
It would be nice to get this done within the next week or two so that we
have time to shake out issues before the next release.
Regards,
Dave Barnes on behalf of the Apache Geode Team

[ANNOUNCE] Apache Geode 1.13.0

[Dave Barnes]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.13.


Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.


Geode 1.13 contains some new gfsh commands and support for the Server Name
Indication (SNI) extension to TLS, as well as a number of improvements and
bug fixes.


Users are encouraged to upgrade to the latest release. For the full list of
changes please review the release notes:

https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.0


The release artifacts can be downloaded from the project website:

http://geode.apache.org/releases/


The release documentation is available at:

http://geode.apache.org/docs/guide/113/about_geode.html


We would like to thank all the contributors that made the release possible.


Regards,

Dave Barnes on behalf of the Apache Geode team

Re: Geode 1.13 RC1 accepted

[Dave Barnes]

Good advice, Bruce. Thanks for the +1.

On Thu, Sep 10, 2020 at 9:53 AM Bruce Schuchardt  wrote:

> I missed the vote but am okay with it.  Maybe not start a 3-day vote on a
> holiday next time?
>
> On 9/9/20, 3:49 PM, "Dave Barnes"  wrote:
>
> It's past the announced deadline and we have closed the vote with a
> successful result.
>
> Voting status
> ==
> +1 10 votes (*=PMC member, 'binding' vote)
>
> Aaron Lindsey
>
> Dave Barnes*
>
> Jens Deppe*
>
> Jinmei Liao*
>
> John Blum*
>
> Mike Martell
>
> Nabarun Nag*
>
> Owen Nichols
>
> Patrick Johnson
>
> Sarah Abbey
>
>
> +0: zero votes
>
> -0: zero votes
>
> -1: zero votes
>
>
> The voting meets the requirements of at least 3 PMC members with +1
> votes
> and has the required majority of +1 votes.
>
> Apache Geode 1.13.RC1 has passed the vote. We will finalize the release
> shortly.
>
>
> Thanks everyone for the great work!
>
> -Dave
>
>

[VOTE] Apache Geode 1.13.0.RC1

[Dave Barnes]

Hello Geode Dev Community,


This is a release candidate for Apache Geode version 1.13.0.RC1.

Thanks to all the community members for their contributions to this release!


Please do a review and give your feedback, including the checks you
performed.


Voting deadline:

3PM PDT Wed, September 9, 2020.


Please note that we are voting upon the source tag:

rel/v1.13.0.RC1


Release notes:

https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.0


Source and binary distributions:

https://dist.apache.org/repos/dist/dev/geode/1.13.0.RC1/


Maven staging repo:

https://repository.apache.org/content/repositories/orgapachegeode-1069


GitHub:

https://github.com/apache/geode/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-examples/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-native/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-benchmarks/tree/rel/v1.13.0.RC1


Pipelines:

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-rc


Geode's KEYS file containing PGP keys we use to sign the release:

https://github.com/apache/geode/blob/develop/KEYS


Command to run geode-examples:

./gradlew -PgeodeReleaseUrl=
https://dist.apache.org/repos/dist/dev/geode/1.13.0.RC1
-PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1069
build runAll


Regards

Dave Barnes

Geode 1.13 RC1 accepted

[Dave Barnes]

It's past the announced deadline and we have closed the vote with a
successful result.

Voting status
==
+1 10 votes (*=PMC member, 'binding' vote)

Aaron Lindsey

Dave Barnes*

Jens Deppe*

Jinmei Liao*

John Blum*

Mike Martell

Nabarun Nag*

Owen Nichols

Patrick Johnson

Sarah Abbey


+0: zero votes

-0: zero votes

-1: zero votes


The voting meets the requirements of at least 3 PMC members with +1 votes
and has the required majority of +1 votes.

Apache Geode 1.13.RC1 has passed the vote. We will finalize the release
shortly.


Thanks everyone for the great work!

-Dave

Re: [PROPOSAL] Backport GEODE-8475 to 1.13

[Dave Barnes]

Yes, Gester - thanks.

> On Sep 2, 2020, at 3:04 PM, Owen Nichols  wrote:
> 
> +1, looking forward to getting this backported as soon as possible today!
> 
> On 9/2/20, 2:34 PM, "Eric Shu"  wrote:
> 
>+1
> 
>
>From: Dick Cavender 
>Sent: Wednesday, September 2, 2020 11:07 AM
>To: dev@geode.apache.org 
>Subject: RE: [PROPOSAL] Backport GEODE-8475 to 1.13
> 
>+1
> 
>-Original Message-
>From: Anilkumar Gingade 
>Sent: Wednesday, September 2, 2020 11:05 AM
>To: dev@geode.apache.org
>Subject: Re: [PROPOSAL] Backport GEODE-8475 to 1.13
> 
>+1 As it address a potential hang.
> 
>-Anil.
> 
> 
>On 9/2/20, 10:38 AM, "Xiaojian Zhou"  wrote:
> 
>Hi, All:
> 
>I want to backport my fix in GEODE-8475 to 1.13. It fixed a hang 
> caused by a potential deadlock.
> 
>This fix is quite safe, I have verified it by running all queue 
> related regression.
> 
>Regards
>Gester
> 
> 

Re: [PROPOSAL] port GEODE-8467 to support/1.13

[Dave Barnes]

+1
GEODE-8467 addresses one of the few remaining 1.13 release blockers.
I see it's been approved and merged into the develop branch. Assuming that
it's passed applicable testing, let's do it.

On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt  wrote:

> I’d like to cherry-pick this change into support/1.13:
>
> There is a flaw in the code that handles a server being forced out of the
> cluster.  The flaw keeps the server from shutting down and leaves the
> server in a hung state.  The PR adds error handling to two methods, one in
> the Cache’s XML-generation method and the other in a Membership class to
> ensure that tear-down of the cache is performed.
>
> https://github.com/apache/geode/pull/5490
>
>

Re: [PROPOSAL] port GEODE-8467 to support/1.13

[Dave Barnes]

> Assuming that it's passed applicable testing AND GETS AT LEAST 3 VOTES,
let's do it.

On Tue, Sep 1, 2020 at 10:24 AM Dave Barnes  wrote:

> +1
> GEODE-8467 addresses one of the few remaining 1.13 release blockers.
> I see it's been approved and merged into the develop branch. Assuming that
> it's passed applicable testing, let's do it.
>
> On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt  wrote:
>
>> I’d like to cherry-pick this change into support/1.13:
>>
>> There is a flaw in the code that handles a server being forced out of the
>> cluster.  The flaw keeps the server from shutting down and leaves the
>> server in a hung state.  The PR adds error handling to two methods, one in
>> the Cache’s XML-generation method and the other in a Membership class to
>> ensure that tear-down of the cache is performed.
>>
>> https://github.com/apache/geode/pull/5490
>>
>>

Re: Proposal to bring GEODE-8456 (shiro upgrade) to support branches

[Dave Barnes]

Looks like more than enough approvals, Owen. Please port, as you proposed.
Thanks,
Dave

On Tue, Sep 1, 2020 at 7:45 AM Alexander Murmann 
wrote:

> +1
>
> On Tue, Sep 1, 2020 at 6:19 AM Sarah Abbey  wrote:
>
> > +1
> > 
> > From: Ju@N 
> > Sent: Tuesday, September 1, 2020 4:10 AM
> > To: dev@geode.apache.org 
> > Subject: Re: Proposal to bring GEODE-8456 (shiro upgrade) to support
> > branches
> >
> > +1
> >
> > On Tue, 1 Sep 2020 at 01:11, Donal Evans  wrote:
> >
> > > +1
> > >
> > > We still have outstanding release blockers for 1.13, so getting this
> fix
> > > in now just prevents extra work in the future without slowing us down
> > now.
> > > 
> > > From: Owen Nichols 
> > > Sent: Monday, August 31, 2020 4:19 PM
> > > To: dev@geode.apache.org 
> > > Subject: Proposal to bring GEODE-8456 (shiro upgrade) to support
> branches
> > >
> > > Recently shiro-1.5.3.jar is getting flagged for ‘high’ security
> > > vulnerability CVE-2020-13933.
> > >
> > > Analysis shows that Geode does not use Shiro in a manner that would
> > expose
> > > this vulnerability.
> > >
> > > The risk of bringing GEODE-8456 is low (difference between Shiro 1.5.3
> > and
> > > 1.6.0 is bugfix and dependency bump only).  GEODE-8456 has been on
> > develop
> > > for 6 days and passed all tests.
> > >
> > > This fix is critical to avoid false positives in automated
> vulnerability
> > > scans.  It would be nice to bring to support branches before 1.13.0 is
> > > released.
> > >
> > > Please vote “+1” to approve including this in 1.13.0.  If there are any
> > -1
> > > votes, I’ll wait until after 1.13.0 is done to propose this again.
> > >
> >
> >
> > --
> > Ju@N
> >
>

Re: [PROPOSAL] port GEODE-8467 to support/1.13

[Dave Barnes]

OK Bruce, go for it.
Thanks for the fix.
Dave

On Tue, Sep 1, 2020 at 10:43 AM Sarah Abbey  wrote:

> +1
> 
> From: Donal Evans 
> Sent: Tuesday, September 1, 2020 1:38 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13
>
> +1
> ________
> From: Dave Barnes 
> Sent: Tuesday, September 1, 2020 10:25 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13
>
> > Assuming that it's passed applicable testing AND GETS AT LEAST 3 VOTES,
> let's do it.
>
> On Tue, Sep 1, 2020 at 10:24 AM Dave Barnes  wrote:
>
> > +1
> > GEODE-8467 addresses one of the few remaining 1.13 release blockers.
> > I see it's been approved and merged into the develop branch. Assuming
> that
> > it's passed applicable testing, let's do it.
> >
> > On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt 
> wrote:
> >
> >> I’d like to cherry-pick this change into support/1.13:
> >>
> >> There is a flaw in the code that handles a server being forced out of
> the
> >> cluster.  The flaw keeps the server from shutting down and leaves the
> >> server in a hung state.  The PR adds error handling to two methods, one
> in
> >> the Cache’s XML-generation method and the other in a Membership class to
> >> ensure that tear-down of the cache is performed.
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5490data=02%7C01%7Csabbey%40vmware.com%7Cbe14c93b2d4d43e31f7708d84e9dd689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637345787113051903sdata=TsXIb6rNEAChlQPdDoGztVBayA70xlhGldyktCJwKW4%3Dreserved=0
> >>
> >>
>

Re: [VOTE] Apache Geode 1.13.0.RC1

[Dave Barnes]

+1
- Built the Geode user guide from source
- Verified the Geode API docs in the binary distribution are correct
- Built the Geode Native user guides (.NET and C++) from source
- Built the Geode Native API docs from source

On Tue, Sep 8, 2020 at 2:05 PM Nabarun Nag  wrote:

> +1 Based on the following tasks
> Clean build
> Starting gfsh, executing queries.
> meld comparison of artifacts directories.
>
> 
> From: Jinmei Liao 
> Sent: Tuesday, September 8, 2020 11:16 AM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Apache Geode 1.13.0.RC1
>
> +1
> Verified geode management rest urls are working as expected.
>
> On 9/8/20, 9:53 AM, "Owen Nichols"  wrote:
>
> +1
>
> I have reviewed test results for a battery of internal functional and
> performance tests, reviewed the LICENSE file for accuracy, looked at the
> logs for all checks in the rc pipeline, confirmed that artifact files are
> now named consistently as requested last time, confirmed gfsh and gfsh
> version --full output, reviewed the release notes in the wiki, reviewed
> that the fixed list in Jira is accurate, and checked that the RC1 tag shows
> as "Verified" in github.
>
> On 9/7/20, 8:23 PM, "Dave Barnes"  wrote:
>
> Hello Geode Dev Community,
>
>
> This is a release candidate for Apache Geode version 1.13.0.RC1.
>
> Thanks to all the community members for their contributions to
> this release!
>
>
> Please do a review and give your feedback, including the checks you
> performed.
>
>
> Voting deadline:
>
> 3PM PDT Wed, September 9, 2020.
>
>
> Please note that we are voting upon the source tag:
>
> rel/v1.13.0.RC1
>
>
> Release notes:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.0data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rKGO6MdK93hSTJF%2F%2BN%2FIJ3Vd5vNeq1BQBRAGI77Ip4g%3Dreserved=0
>
>
> Source and binary distributions:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1%2Fdata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=x6vVgr6ceI0196EMCbmUq6WxAqixcSgARBhC0D1T%2BdM%3Dreserved=0
>
>
> Maven staging repo:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=fs1Mi7y3fEt7Bnfyl9KnJTKXWHTazsFdCmtUtUMS4Hs%3Dreserved=0
>
>
> GitHub:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=awSnw4fkDLxhVamoAM%2FsBSAGhaTi9KroI4Jlp5Lg8%2FE%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rK5NNxqocS0v1CakZ5xdNi7lq1IHz4UojJzx5AS7LVw%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rQG4MSWw%2FHxWAj4tdBLrE24Q1ukFa5ipI%2FWsDka9GaI%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=9o7QtQAGg%2BSkjc5xNmxElJPJfFvJ1I8%2FvlErm1LMGc8%3Dreserved=0
>
>
> Pipelines:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424628973sdata=OR6viVpRZtN6rSz9qOH6xPwdYoUuaJDUCXp%2FIcd2ens%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelin

Re: [PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s"

[Dave Barnes]

+1 esp addition of "Affects Version/s".

On Mon, Aug 17, 2020 at 3:07 PM Kirk Lund  wrote:

> +1 if it's possible
>
> On Mon, Aug 17, 2020 at 12:04 PM Donal Evans  wrote:
>
> > Looking at the dialogue that opens when you attempt to create a new
> ticket
> > in the GEODE Jira[1], there are two fields included that aren't really
> > necessary and may cause confusion. The "Fix Version/s" field should
> > presumably not be filled out until the issue has actually been fixed,
> > rather than at the time of ticket creation. The "Sprint" field seems to
> no
> > longer serve any purpose at all that I can discern, having only been
> filled
> > in 13 tickets, the most recent of which was created in December 2018[2].
> > With the expansion of the community contributing to the Geode project,
> it's
> > important to provide a straightforward experience for people who are new
> to
> > the project and wish to file tickets, so the presence of these fields may
> > cause issues.
> >
> > I propose that these two fields be removed from the "Create Issue"
> > dialogue and that the "Affects Version/s" field be added, since that
> field
> > is far more important at time of ticket creation. There are currently
> 3851
> > bug tickets in the Jira with no "Affects Version/s" value entered at
> > all[3], which I suspect is in part due to that field not being an option
> in
> > the "Create Issue" dialogue, meaning you have to remember to go back
> after
> > creating the ticket and enter it. With Geode moving to a model of having
> > support branches and patch releases, properly capturing the versions
> > affected by a given issue becomes even more important.
> >
> > [1] https://i.imgur.com/oQ8CW87.png
> > [2]
> >
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8433?filter=allissues=cf%5B12310921%5D+ASC%2C+created+DESC
> > [3]
> >
> https://issues.apache.org/jira/browse/GEODE-8433?jql=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%20affectedVersion%20%3D%20EMPTY%20ORDER%20BY%20created%20DESC%2C%20affectedVersion%20ASC%2C%20cf%5B12310921%5D%20ASC
> >
>

Re: [PROPOSAL] Backport GEODE-8432 to 1.13

[Dave Barnes]

Thanks for your contribution, Gester

On Thu, Aug 20, 2020 at 12:37 PM Joris Melchior 
wrote:

> +1
>
> On 2020-08-20, 12:08 PM, "Xiaojian Zhou"  wrote:
>
> It's using region path instead of getting the region. It should be no
> risk.
>
> On 8/19/20, 10:25 AM, "Xiaojian Zhou"  wrote:
>
> This problem also exists in 1.13.
>
>
>

Re: Clean C++ client metadata in timeouts

[Dave Barnes]

If a straight-up change solves a constant headache, as you suggest,
Alberto, and as Blake concurs, that sounds like the way to go.
Why introduce a new option or property if the user will always prefer one
behavior over the other? (And from a docs perspective, who needs another
optional property, anyway?)

On Thu, Sep 17, 2020 at 10:32 AM Blake Bender  wrote:

> Given that attempts to retrieve metadata after the C++ cache is closed are
> a constant headache for Geode Native development, I am generally in favor
> of anything that potentially reduces the number of times/places this
> happens.  If we've failed the handshake, it's very unlikely things will
> correct themselves without outside intervention, so this fix is probably
> goodness.  I'd go ahead and submit a PR when you think it's solid.
>
> Thanks,
>
> Blake
>
>
> On 9/17/20, 9:36 AM, "Dave Barnes"  wrote:
>
> Alberto,
> Are there cases in which one or two timeouts are followed by a
> successful
> retry? Or does one timeout *always* end with more timeouts and,
> ultimately,
> an IO error?
> If timeouts can sometimes be followed by successful retries, and
> re-trying
> is the current default behavior, then I agree that introducing a
> setting
> that effectively eliminates re-tries should be the developer's choice.
> In that case, I suggest that the option should not be a low-level
> choice of
> "handle the metadata in a way that eliminates retries" but should be
> higher
> level, like "when attempting to connect, try only once, instead of
> re-trying (the default behavior)."
> -Dave
>
> On Thu, Sep 17, 2020 at 7:42 AM Alberto Bustamante Reyes
>  wrote:
>
> > Hi geode-dev,
> >
> > I have a question about the c++ client.
> >
> > Some months ago we merged GEODE-8231 to solve a problem we observed
> > regarding the native client was trying to connect to stopped server.
> > GEODE-8231 solution consists on remove the client metadata when an
> "IO
> > error in handshake" exception is received. This fix solved most of
> our
> > problems, but it has been observed that sometimes when a server is
> stopped
> > the errors received in the client are not the same and this "IO
> error in
> > handshake" takes up to a minute to appear. So during that time, the
> client
> > is still trying to connect to the offline server.
> >
> > As the error received during that time is "timeout in handshake", we
> have
> > tested modyfing the solution of GEODE-8213 to make the client to
> remove the
> > metadata once a timeout error is received (here is a draft with the
> code:
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F651data=02%7C01%7Cbblake%40vmware.com%7Cee9cfd61173047c7247808d85b27c3c8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637359573636742453sdata=FUhQIAalNs0PK4vFvgnVZPV55cLPykD2cvDRwgRrNj0%3Dreserved=0).
> With this change in
> > place, the behavior is ok.
> >
> >
> > But I would like to check your opinion about this check, because
> this will
> > cause that a single timeout will cause the removal of the client
> metadata,
> > which maybe its not the best solution. I thought about different
> > alternatives:
> >
> > - Wait until a given number of timeouts in a row have been received
> from
> > the same server to remove the metadata
> > - Make this "remove-metadata-after-timeout" something optional that
> could
> > be configured if needed
> >
> > As this will misalign the behavior of Java and C++ clients, making
> this an
> > optional configuration will be more appropriate, to keep the default
> c++
> > client behavior as the Java client.
> >
> > BR/
> >
> > Alberto B.
> >
>
>

Re: Clean C++ client metadata in timeouts

[Dave Barnes]

Alberto,
Are there cases in which one or two timeouts are followed by a successful
retry? Or does one timeout *always* end with more timeouts and, ultimately,
an IO error?
If timeouts can sometimes be followed by successful retries, and re-trying
is the current default behavior, then I agree that introducing a setting
that effectively eliminates re-tries should be the developer's choice.
In that case, I suggest that the option should not be a low-level choice of
"handle the metadata in a way that eliminates retries" but should be higher
level, like "when attempting to connect, try only once, instead of
re-trying (the default behavior)."
-Dave

On Thu, Sep 17, 2020 at 7:42 AM Alberto Bustamante Reyes
 wrote:

> Hi geode-dev,
>
> I have a question about the c++ client.
>
> Some months ago we merged GEODE-8231 to solve a problem we observed
> regarding the native client was trying to connect to stopped server.
> GEODE-8231 solution consists on remove the client metadata when an "IO
> error in handshake" exception is received. This fix solved most of our
> problems, but it has been observed that sometimes when a server is stopped
> the errors received in the client are not the same and this "IO error in
> handshake" takes up to a minute to appear. So during that time, the client
> is still trying to connect to the offline server.
>
> As the error received during that time is "timeout in handshake", we have
> tested modyfing the solution of GEODE-8213 to make the client to remove the
> metadata once a timeout error is received (here is a draft with the code:
> https://github.com/apache/geode-native/pull/651). With this change in
> place, the behavior is ok.
>
>
> But I would like to check your opinion about this check, because this will
> cause that a single timeout will cause the removal of the client metadata,
> which maybe its not the best solution. I thought about different
> alternatives:
>
> - Wait until a given number of timeouts in a row have been received from
> the same server to remove the metadata
> - Make this "remove-metadata-after-timeout" something optional that could
> be configured if needed
>
> As this will misalign the behavior of Java and C++ clients, making this an
> optional configuration will be more appropriate, to keep the default c++
> client behavior as the Java client.
>
> BR/
>
> Alberto B.
>

Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12

[Dave Barnes]

Thanks, Udo - Go ahead with your proposed back-port.
Dave

On Wed, May 27, 2020 at 6:50 AM Jinmei Liao  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Tuesday, May 26, 2020 4:09 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12
>
> +1
>
> On 5/26/20, 4:04 PM, "Eric Shu"  wrote:
>
> +1
>
> 
> From: Udo Kohlmeyer 
> Sent: Tuesday, May 26, 2020 2:12 PM
> To: geode 
> Subject: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12
>
> Hi there Geode Dev,
>
> I would like to request a back port of a critical issue in the
> JCAConnectionManager. This issue manifests itself as a
> ConcurrentModificationException when trying to close a connection.
>
> SHA: bef07b34131abddb8c0f04e0ab6a48f1daac991d
>
> —Udo
>
>

Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12

[Dave Barnes]

Udo, please remember to update the JIRA ticket - it needs to be closed and
the fix-versions specified.
Thanks,
Dave

On Wed, May 27, 2020 at 7:24 AM Dave Barnes  wrote:

> Thanks, Udo - Go ahead with your proposed back-port.
> Dave
>
> On Wed, May 27, 2020 at 6:50 AM Jinmei Liao  wrote:
>
>> +1
>> 
>> From: Owen Nichols 
>> Sent: Tuesday, May 26, 2020 4:09 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12
>>
>> +1
>>
>> On 5/26/20, 4:04 PM, "Eric Shu"  wrote:
>>
>> +1
>>
>> 
>> From: Udo Kohlmeyer 
>> Sent: Tuesday, May 26, 2020 2:12 PM
>> To: geode 
>> Subject: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12
>>
>> Hi there Geode Dev,
>>
>> I would like to request a back port of a critical issue in the
>> JCAConnectionManager. This issue manifests itself as a
>> ConcurrentModificationException when trying to close a connection.
>>
>> SHA: bef07b34131abddb8c0f04e0ab6a48f1daac991d
>>
>> —Udo
>>
>>

Re: [PROPOASAL] backport GEODE-8144

[Dave Barnes]

I'm going to spend a release-manager +1 to put this proposal over the top.
Please merge this fix into support/1.13, Bruce.
Thanks,
Dave

On Thu, May 28, 2020 at 7:52 AM Udo Kohlmeyer  wrote:

> +1
> On May 27, 2020, 1:35 PM -0700, Bruce Schuchardt ,
> wrote:
> This ticket has two PRs. One passed all normal CI runs but then we hit a
> faulty test that failed on a Windows machine. There’s a new PR that fixes
> that test & has been merged.
>
> The PRs fixe endpoint verification problems in servers and locators.
> Without this fix it’s not possible to boot a locator/server with endpoint
> verification enabled.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5164data=02%7C01%7Cudo%40vmware.com%7C0796e6c983d444e87feb08d8027d7ce8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085284295283sdata=sqhirE3DudI00gOpLHlGYTHG9T8GPNVaJK7GB6rSl%2Bc%3Dreserved=0
> fixes the failing test
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cudo%40vmware.com%7C0796e6c983d444e87feb08d8027d7ce8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085284305283sdata=BruRleV2p%2BRVg5mWBEt8LPWrCsMKUClogFX8VInanmc%3Dreserved=0
> is the original PR
>
> both have been merged to develop
>
>
>

Re: No more hardcoded region separators!

[Dave Barnes]

Excellent, Donal!
If you have not already done so, please consider documenting the practice
you're advocating in a place where all community contributors have a chance
of seeing it. Maybe
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute?

On Thu, May 28, 2020 at 9:46 AM Donal Evans  wrote:

> I'm happy to say that as of about 5 minutes ago, there are no uses of
> hardcoded "/" in region paths/names in the geode codebase, as all of them
> have been replaced by the Region.SEPARATOR constant (with the exception of
> a few occurrences in the geode-management module, which while not having an
> explicit dependency on geode-core has implicit dependencies on some things
> like the region separator, index types etc). I'd like to request that going
> forward, we maintain this convention of only using Region.SEPARATOR and
> avoid introduction of any new hardcoded "/" characters in code pertaining
> to region paths or names, both in our own commits and in commits we review
> from other developers.
>

Re: PR process and etiquette

[Dave Barnes]

Here's a common use case that we should address: A single PR may require
two reviews, one for code and another for docs, before it can be said to be
fully reviewed and ready to merge.
Points to consider:

   - Many PRs, especially those introducing new features or user-settable
   properties, include both code and docs. "Docs" includes updates to the user
   guide sources, but also code comments that are consumed by community
   developers and are included in the auto-generated API documentation.
   Parameter name choices, explanations, spelling and grammar need to be right.
   - Reviews of code and docs require different skills, so a good-quality
   PR review in such cases benefits from multiple reviewers, (at least) one
   for code, and (at least) one for docs.
   - [My key concern] Current protocol is 1 reviewer approval qualifies the
   PR for merging. I flag my doc reviews in such cases with a note to the
   submitter saying something like "Docs reviewed and approved; technical
   review still needed before merging". But a submitter who's eager to merge
   may just see green and go for it, without reading the caveat. I'm against
   enforcing a multiple-review requirement. What I would like to see is a
   status for partial approval, so I can register my approval without
   prematurely opening the door to a code merge.
   - Other considerations:
  - There are PRs that don't fit this two-part use case. Many PRs are
  code-only, with no doc component. Conversely, some PRs are
docs-only, with
  no code component.
  - PRs often are not recognized as falling into this two-part use
  case. Submitters of JIRA tickets may not know whether the solution to the
  problem they're reporting will affect docs. Submitter of the PR
addressing
  the JIRA ticket may not think to add the 'docs' component to the related
  JIRA ticket or to request a doc reviewer when creating the PR.


On Wed, Oct 28, 2020 at 8:41 AM Robert Houghton 
wrote:

> There are some pieces of Apache infrastructure we can control without
> needing tickets: Specifically
> required_pull_request_reviews:
> dismiss_stale_reviews: true
> require_code_owner_reviews: true
>
> I think these specific controls could go a long way towards helping keep
> our PR quality high, while reducing cognitive load for the reviewers.
>
> Full documentation here<
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> >
>
>
>
> From: Bruce Schuchardt 
> Date: Wednesday, October 28, 2020 at 8:10 AM
> To: dev@geode.apache.org 
> Subject: Re: PR process and etiquette
> -1
> While I often use the Draft option I don't see why we want to add even
> more rules about how we use github.  I think it's enough to put in a PR and
> then add reviewers when you're ready for comments.  Getting the stink-eye
> for putting up a non-Draft PR is just going to make it more difficult to
> attract and retain new contributors.
>
> On 10/27/20, 5:41 PM, "Udo Kohlmeyer"  wrote:
>
> Dear Apache Geode Devs,
> It is really great going through all the PRs that been submitted. As
> Josh Long is known to say: "I work for PRs".
> Whilst going through some of the PRs I do see that there are many PRs
> that have multiple commits against the PR.
> I know that the PR submission framework kicks off more testing than we
> do on our own local machines. It is extremely uncommon to submit a PR the
> first time and have all tests go green. Which h means we invariably iterate
> over commits to make the build go green.
> In this limbo time period, it is hard for any reviewer to know when
> the ticket is ready to be reviewed.
> I want to propose that when submitting a PR, it is initially submitted
> as a DRAFT PR. This way, all test can still be run and work can be done to
> make sure "green" is achieved. Once "green" status has been achieved, the
> draft can then be upgraded to a final PR by pressing the "Ready For Review"
> button. At this point all commits on the branch can then once again be
> squashed into a single commit.
> Now project committers will now know that the PR is in a state that it
> can be reviewed for completeness and functionality.
> In addition, it will help tremendously helpful if anyone submitting a
> PR monitors their PR for activity. If there is no activity for a few days,
> please feel free to ping the Apache Geode Dev community for review. If
> review is request, please prioritize some time to address the feedback, as
> reviewers spend time reviewing code and getting an understanding what the
> code is doing. If too much time goes by, between review and addressing the
> review comments, not only does the reviewer lose context, possibly
> requiring them to spend time again to understand what the code was/is
> supposed to do, but also possibly lose interest, as the ticket has now
> become cold or dropped down the list of PRs.
> There are currently 

Re: Proposal to backport GEODE-8395 (gfsh help banner) to support branches

[Dave Barnes]

+1


On Sun, Aug 2, 2020 at 7:07 AM Donal Evans  wrote:

> +1
>
> Nice catch!
>
> Get Outlook for Android
>
> 
> From: Jinmei Liao 
> Sent: Saturday, August 1, 2020 11:09:45 PM
> To: dev@geode.apache.org 
> Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to support
> branches
>
> +1
>
> On Aug 1, 2020 10:30 PM, Owen Nichols  wrote:
> This issue was present since Geode 1.0.  There is zero risk from this fix,
> which is already on develop.  It is critical because Geode releases are a
> legal Act of the Apache Foundation and should not misrepresent the identity
> of the project.
>
> Here’s the issue:
>
> $ gfsh
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  /
> / /__/ / /  _/ / // /
> /__/_/  /__/_//_/1.12.0
>
> Monitor and Manage Apache Geode<-- right product name
>
> $gfsh --help
> Pivotal GemFire(R) v1.12.0 Command Line Shell   <-- WRONG product name
>
> The “right” instance above was fixed 5 years ago.  GEODE-8395 fixes gfsh
> to use the “right” code in both places.  Please vote +1 to backport this
> fix to support/1.13 and support/1.12.
>
>
>

Re: Proposal to backport GEODE-8395 (gfsh help banner) to support branches

[Dave Barnes]

Hard to believe this problem was still hanging around. Definitely
back-port, the sooner, the better.

On Mon, Aug 3, 2020 at 7:56 AM Dave Barnes  wrote:

> +1
>
>
> On Sun, Aug 2, 2020 at 7:07 AM Donal Evans  wrote:
>
>> +1
>>
>> Nice catch!
>>
>> Get Outlook for Android<https://aka.ms/ghei36>
>>
>> 
>> From: Jinmei Liao 
>> Sent: Saturday, August 1, 2020 11:09:45 PM
>> To: dev@geode.apache.org 
>> Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to
>> support branches
>>
>> +1
>>
>> On Aug 1, 2020 10:30 PM, Owen Nichols  wrote:
>> This issue was present since Geode 1.0.  There is zero risk from this
>> fix, which is already on develop.  It is critical because Geode releases
>> are a legal Act of the Apache Foundation and should not misrepresent the
>> identity of the project.
>>
>> Here’s the issue:
>>
>> $ gfsh
>> _ __
>>/ _/ __/ __/ // /
>>   / /  __/ /___  /_  / _  /
>> / /__/ / /  _/ / // /
>> /__/_/  /__/_//_/1.12.0
>>
>> Monitor and Manage Apache Geode<-- right product name
>>
>> $gfsh --help
>> Pivotal GemFire(R) v1.12.0 Command Line Shell   <-- WRONG product name
>>
>> The “right” instance above was fixed 5 years ago.  GEODE-8395 fixes gfsh
>> to use the “right” code in both places.  Please vote +1 to backport this
>> fix to support/1.13 and support/1.12.
>>
>>
>>

Re: [PROPOSAL] backport GEODE-6564 to support/1.13

[Dave Barnes]

Go ahead and back-port, Darrel. Thanks for your contribution.

On Mon, Aug 3, 2020 at 4:51 PM Alexander Murmann 
wrote:

> +1
>
> On Mon, Aug 3, 2020 at 4:47 PM Jianxia Chen  wrote:
>
> > +1
> >
> > On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider 
> wrote:
> >
> > > GEODE-6564 is a memory leak that has impacted users so it would be good
> > to
> > > have it in 1.13. It has a simple, low risk, fix.
> > >
> >
>

Re: [PROPOSAL] backport GEODE-8394 to support/1.13

[Dave Barnes]

Plenty of approvals. Go ahead and port, Anil. Thanks!

On Fri, Aug 7, 2020 at 11:08 AM Owen Nichols  wrote:

> +1 and please bring to support/1.12 as well
>
> On 8/7/20, 10:49 AM, "Jianxia Chen"  wrote:
>
> +1
>
> On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade  >
> wrote:
>
> > This causes a large object to be partially (corrupt data) stored in
> cache
> > instead of throwing an exception.
> >
> >
>
>

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

+1


On Wed, Aug 12, 2020 at 9:10 AM Darrel Schneider  wrote:

> +1
> 
> From: Sarah Abbey 
> Sent: Wednesday, August 12, 2020 8:59 AM
> To: dev@geode.apache.org 
> Subject: [PROPOSAL] Backport GEODE-8423 to support/1.13
>
> The documentation for the Redis API for Geode that will currently be
> published for 1.13 is not accurate and needs to be updated so potential
> users searching for information about Redis API for Geode will get accurate
> information.
>

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

OK, Sarah, you have the requisite 3 votes -- go ahead and back-port.
Thanks for your contribution!
-Dave

On Wed, Aug 12, 2020 at 9:24 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Aug 12, 2020, at 8:59 AM, Sarah Abbey  sab...@vmware.com>> wrote:
>
> get
>
>

[PROPOSAL] back-port GEODE-8388 native client doc fixes to support/1.13

[Dave Barnes]

GEODE-8388: Geode Native Client user guide: delete unused sources

Housekeeping: The geode-native docs directory contains unused sources from
the pre-open-source days. The problem is that while they're not linked to
the user guide's T of C, these out-of-date docs are still included in the
manual build (a quirk of the toolset), where they can be accidentally
discovered via web searches.

These unused files need to be identified and deleted.

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Dave Barnes]

Has the version on the develop branch completed a test cycle?

On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen  wrote:

> +1
>
> On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:
>
> > Hi All,
> >
> > We have found a case where tombstones were being cleared when the region
> > was not initialized. This was causing some test failures and potential
> > field failures. We would like to put this into support/1.13.
> >
> > Thanks,
> > Mark
> >
>

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Dave Barnes]

Do I understand correctly that this fix, if validated, addresses the last
remaining release-blocker for 1.13?

On Wed, Aug 12, 2020 at 6:02 PM Mark Hanson  wrote:

> Not yet, we will need to wait for that to finish cleanly relative to this
> change. I guess I was just seeking to gain approval for priority of it once
> it does pass. (Maybe I am being a little over zealous).
>
> Thanks,
> Mark
>
> On 8/12/20, 5:52 PM, "Dave Barnes"  wrote:
>
> Has the version on the develop branch completed a test cycle?
>
> On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen 
> wrote:
>
> > +1
> >
> > On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson 
> wrote:
> >
> > > Hi All,
> > >
> > > We have found a case where tombstones were being cleared when the
> region
> > > was not initialized. This was causing some test failures and
> potential
> > > field failures. We would like to put this into support/1.13.
> > >
> > > Thanks,
> > > Mark
> > >
> >
>
>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

OK, Gester, please merge.
Thanks,
Dave

On Wed, Jul 1, 2020 at 8:33 AM Bruce Schuchardt  wrote:

> +1
> I reviewed this PR and, as Gester said, it's low risk.  If it fixes a
> problem someone is having let's backport it.
>
> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>
> Customer encountered a singlehop getAll failure due to
> SerializationException which is identified as socket error. The
> solution is
> to retry the getAll in this race condition (currently we did not
> retry).
>
>
> The fix is tested in both develop and support branches. The fix is
> conservative and very low risk.
>
>
>
> So it would be nice to bring to before 1.13.0 release.
>
>
>
> Regards
>
> Xiaojian Zhou
>
>

Re: Back-Port GEODE-8240 to 1.12, 1.13

[Dave Barnes]

Hey, Bill, you got the votes. Go ahead with the back-ports.
Thanks,
Dave

On Wed, Jul 1, 2020 at 10:54 AM Kirk Lund  wrote:

> +1
>
> On Wed, Jul 1, 2020 at 9:59 AM Dick Cavender  wrote:
>
> > +1
> >
> > -Original Message-
> > From: Bruce Schuchardt 
> > Sent: Wednesday, July 1, 2020 9:49 AM
> > To: dev@geode.apache.org
> > Subject: Re: Back-Port GEODE-8240 to 1.12, 1.13
> >
> > +1
> >
> > On 7/1/20, 9:43 AM, "Bill Burcham"  wrote:
> >
> > I'd like permission to back-port the fix for rolling upgrade bug
> > GEODE-8240
> > to support/1.12 and support/1.13
> >
> > -Bill
> >
> >
>

Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13

[Dave Barnes]

Thanks, Bruce.

On Thu, Jul 9, 2020 at 10:32 AM Bruce Schuchardt  wrote:

> Since I had 3 +1’s I merged the change to support/1.13
>
> From: Bruce Schuchardt 
> Date: Thursday, July 9, 2020 at 8:00 AM
> To: "dev@geode.apache.org" 
> Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
>
> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 branch,  but performance on develop okay.
> The only communications changes in develop that aren’t in 1.13 are those
> that fixed this long-standing bug, so I’d like to backport it to the 1.13
> branch.
>
> https://github.com/apache/geode/pull/5048
>
> The error was in the cluster communications message-streamer class that
> created some extra objects during message transmission.  The fix is small
> and has been, at this point, through many test iterations.
>

Re: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13

[Dave Barnes]

Sounds like an improvement, Juan, and you’ve got the votes.
Go ahead and back port. 
Thanks,
Dave

> On Jul 3, 2020, at 9:08 AM, Joris Melchior  wrote:
> 
> +1
> 
> On 2020-07-03, 9:06 AM, "Ju@N"  > wrote:
> 
>Hello devs,
> 
>I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and
>support/1.13 branches.
>No, you're not having deja vú (neither this is an error within the Matrix):
>a couple of weeks ago I've backported another fix for the same ticket to
>the mentioned branches and sent the proposal to the list with exactly the
>same subject, but it has proven to be problematic and introduced some
>regressions... sorry about that.
>The new fix uses a different approach, solves the original issue and
>doesn't introduce any new problems (feel free to have a look at the ticket
>for further details); it has been merged into develop already through
>commit fdc4401 [2]. As a side note, I've also created a new ticket
>(GEODE-8325 [3]) to improve the internal behavior and implement a long term
>solution to avoid the proliferation of unused drf files.
>Best regards.
> 
>[1]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=7%2F%2BN0mPrBss1LooT7Fu605r%2BDhYGG3JnLslQlL0pNLs%3Dreserved=0
>  
> 
>[2]:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Ffdc440131f0d562d97f2340d2e7ba5aacf935d62data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=z5ztkjZ9RBsD32hE5FL3W5J%2Bc6xZh7YUYHVpruNgpjs%3Dreserved=0
>  
> 
>[3]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8325data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=gXIoTE2JXozzKTwVknNdpdvAovJyoG0nM01w3Nb%2FINc%3Dreserved=0
>  
> 
> 
> 
>-- 
>Ju@N

Re: [VOTE] change Default branch for geode-examples to 'develop'

[Dave Barnes]

+1

> On Jul 9, 2020, at 10:04 PM, Dick Cavender  wrote:
> 
> +1
> 
> -Original Message-
> From: Owen Nichols  
> Sent: Thursday, July 9, 2020 9:39 PM
> To: dev@geode.apache.org
> Subject: [VOTE] change Default branch for geode-examples to 'develop'
> 
> A fresh checkout of geode and all but one geode- repos checks 
> out develop as the Default branch.
> 
> The lone exception is geode-examples.  Please vote +1 if you are in favor of 
> changing its Default branch to develop for consistency with the other repos 
> and other reasons as per recent discussion[1].
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Cdickc%40vmware.com%7C1a703cc22f784158523008d8248b4188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299527805384154sdata=9BABTC6ROp6h3hD7lsOkezesyc%2BuJFAFQB08BFL7O%2FE%3Dreserved=0

Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

[Dave Barnes]

Thanks for taking care of that, Owen.

On Tue, Jun 30, 2020 at 9:38 AM Owen Nichols  wrote:

> Backported to support/1.13 and support/1.12
>
> On 6/30/20, 9:37 AM, "Robert Houghton"  wrote:
>
> +1
>
> From: Dick Cavender 
> Date: Tuesday, June 30, 2020 at 9:14 AM
> To: dev@geode.apache.org 
> Subject: RE: Proposal to bring GEODE-8315 (shiro upgrade) to support
> branches
> +1
>
> -Original Message-
> From: Ju@N 
> Sent: Tuesday, June 30, 2020 9:12 AM
> To: dev@geode.apache.org
> Subject: Re: Proposal to bring GEODE-8315 (shiro upgrade) to support
> branches
>
> +1
>
> On Tue, 30 Jun 2020 at 17:03, Owen Nichols 
> wrote:
>
> > Recently shiro-1.5.2.jar is getting flagged for critical security
> > vulnerability CVE-2020-11989.
> >
> > Analysis shows that Geode does not use Shiro in a manner that would
> > expose this vulnerability.
> >
> > The risk of bringing GEODE-8315 is very low (difference between Shiro
> > 1.5.2 and 1.5.3 is bugfix only).  GEODE-8315 has been on develop for
> 2
> > days and passed the pipeline.
> >
> > This fix is critical to avoid false positives in automated
> > vulnerability scans, so it would be nice to bring before 1.13.0
> release.
> >
>
>
> --
> Ju@N
>
>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

...and there it is!

On Tue, Jun 30, 2020 at 4:10 PM Dave Barnes  wrote:

> Strange -- I received the two votes 9 minutes before I got the original
> message.
> I'm heading out for the day, so Gester, if you get that third vote, go
> ahead and merge.
> Cheers,
> Dave
>
> On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao  wrote:
>
>> +1
>> 
>> From: Owen Nichols 
>> Sent: Tuesday, June 30, 2020 3:56 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches
>>
>> +1
>>
>> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>>
>> Customer encountered a singlehop getAll failure due to
>> SerializationException which is identified as socket error. The
>> solution is
>> to retry the getAll in this race condition (currently we did not
>> retry).
>>
>>
>> The fix is tested in both develop and support branches. The fix is
>> conservative and very low risk.
>>
>>
>>
>> So it would be nice to bring to before 1.13.0 release.
>>
>>
>>
>> Regards
>>
>> Xiaojian Zhou
>>
>>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

Strange -- I received the two votes 9 minutes before I got the original
message.
I'm heading out for the day, so Gester, if you get that third vote, go
ahead and merge.
Cheers,
Dave

On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Tuesday, June 30, 2020 3:56 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches
>
> +1
>
> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>
> Customer encountered a singlehop getAll failure due to
> SerializationException which is identified as socket error. The
> solution is
> to retry the getAll in this race condition (currently we did not
> retry).
>
>
> The fix is tested in both develop and support branches. The fix is
> conservative and very low risk.
>
>
>
> So it would be nice to bring to before 1.13.0 release.
>
>
>
> Regards
>
> Xiaojian Zhou
>
>

Re: [Proposal] - RFC etiquette

[Dave Barnes]

+1

"Adding a section" (Udo's language) for Use Cases is a positive way of
encouraging RFC authors to provide that material, without saying it's an
iron-clad requirement. Exactly the right way to do it. Commenters can
request more detail when they review it.

On Thu, Jul 9, 2020 at 4:31 PM Donal Evans  wrote:

> Udo,
>
> You're right, and I agree wholeheartedly with your proposal to give RFCs
> enough time and enough context for proper review by as many people as
> possible. Sorry if that didn't come across in my original reply.
> 
> From: Udo Kohlmeyer 
> Sent: Thursday, July 9, 2020 3:55 PM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] - RFC etiquette
>
> Donal,
>
> You have very valid points. All of which only pertain to the “HOW” or “IF”
> an RFC should be written. This being a completely different problem to what
> I’m proposing. I’m willing to comment on any proposal that were to address
> these issues. :)
>
> This proposal is largely aimed at, if there is an existing RFC, we don’t
> try and rush it through and provide more context to reviewers to better
> comment on use case, technical approach or overall soundness of the
> proposal. If we keep aiming RFC’s at specialized technical knowledge, we
> will definitely lose reviewers who have not looked at that code in a long
> time. If the use case(s) are at least described than we can have many
> reviewers who can comment on the feature or technical approach without
> being intimate with all the inner workings of the system.
>
> I believe this approach will help with an overall better understanding of
> the systems behavior.
>
> —Udo
> On Jul 9, 2020, 1:46 PM -0700, Donal Evans , wrote:
> While I definitely approve of these proposals in principle (especially the
> "Use Cases" section, which could really help facilitate discussions around
> other potential solutions/approaches to a problem), the fact that the RFC
> process is still entirely voluntary on the part of the contributor(s) who
> intend to add/modify features in Geode makes me slightly hesitant to add
> extra work/complexity to it. If someone feels like it's too much effort to
> write an RFC, they may decide to skip it and go straight to PR, which for
> large/complex change sets can lead to a lot of missing context for why a
> particular approach was taken and a greater chance of only one or two
> committers actually reviewing the changes in detail rather than the larger
> community being able to weigh in on an RFC.
>
> I feel that RFCs can be a very valuable process to help determine the best
> solution to complex problems, but if there is "too much" work involved in
> creating one and nothing compelling committers to write them, we may end up
> losing out on the value they provide. Perhaps the community could agree on
> some criteria for work that would *require* an RFC, related to the
> scope/breadth of the intended changes and how many different approaches
> there might be? This would have to go hand-in-hand with a commitment from
> the community to promptly and thoroughly review RFCs, though, otherwise
> people could end up being put to the trouble of writing a comprehensive RFC
> only to have barely any actual feedback.
> 
> From: Udo Kohlmeyer 
> Sent: Thursday, July 9, 2020 1:18 PM
> To: geode 
> Subject: [Proposal] - RFC etiquette
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we
> have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This
> is to allow the community to review the RFC in a reasonable timeframe. If
> we rush things, we will miss things. I’d rather have a little more time
> spent on the RFC review and getting the approach “correct” than rushing the
> RFC and then at a later point in time (either at PR review or worse
> production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to
> be labelled “Use Cases”. In this section I would like all submitters to
> describe the use case that this RFC is to fulfill. This would include all
> possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better
> round out each RFC. Causing less delays later in the process and allowing
> all community members to actively participate in the review process
> regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo
>

Re: [PROPOSAL] backport PR #5250 to support/1.13

[Dave Barnes]

Looks good, Bruce. Please backport.


On Tue, Jun 16, 2020 at 4:01 PM Owen Nichols  wrote:

> +1
>
> On 6/16/20, 3:54 PM, "Jianxia Chen"  wrote:
>
> +1
>
> On Tue, Jun 16, 2020 at 3:24 PM Bruce Schuchardt 
> wrote:
>
> > This PR has been merged to develop.  It fixes a problem with the
> previous
> > commit for GEODE-8144 that caused performance degradation when TLS is
> > enabled between servers.  I have run perf tests and verified that it
> fixes
> > the problem.
> >
> > It’s a small change that makes a big difference…
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5250data=02%7C01%7Conichols%40vmware.com%7Ce2ec5e282bb240a6406d08d812484504%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279448892893348sdata=1qOm9MNcOb0JbWE8PTtLJEicYXbO8QglFaPk18VhRss%3Dreserved=0
> >
> >
>
>

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Dave Barnes]

Looks good. Merge to 1.13 (if you haven't already).
-Dave

On Fri, Jun 26, 2020 at 10:05 AM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 9:59 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12
>
> +1
>
> On 6/26/20, 7:58 AM, "Ju@N"  wrote:
>
> +1
>
> On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt 
> wrote:
>
> > This small fix avoids a failure of one cluster to communicate with
> the
> > locators of another cluster, ensuring that a proper handshake for WAN
> > communications occurs.  Without the fix it’s possible that WAN
> connections
> > will not be formed and updates will not be transmitted between sites.
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Cdoevans%40vmware.com%7Cf0fdfd0e9f3f4d1225c508d819f24b53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637287875728618402sdata=ROQYORRw357JRmVBW3gCxRFoptOz%2F%2Fg6oEMoRN4vrhg%3Dreserved=0
> >
> >
>
> --
> Ju@N
>
>

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Dave Barnes]

OK - you've got the votes, Mark, thanks for your contribution.
I'm persuaded by the positive arguments and assurances of low risk.

All: let's focus on getting to RC1. I'm not comfortable with "as this
release has drug on for so long, it might be just about time to reset
expectations". Let's clean up 1.13 and get it out the door.
Thanks,
Dave


On Fri, Jun 26, 2020 at 2:54 PM Owen Nichols  wrote:

> Thank Mark and Donal for detailing the risk and criticality of this
> change.  Since 1.13 is still waiting on a couple other issues, might as
> well take the opportunity to bring this in.  My vote is +1 now.
>
> On 6/26/20, 2:32 PM, "Donal Evans"  wrote:
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
> The "no" regarding the inclusion of a REST api was specifically
> referring to the inclusion of that api's design in the RFC for the restore
> redundancy feature, not whether a REST api for it should exist at all. From
> the RFC: "It is also not within the scope of this RFC to describe any REST
> API that may be created at a future point in time."[1]<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0>
> It was always intended to create a REST api for the restore redundancy
> feature, but it was outside of the scope of my knowledge at the time the
> RFC was created to describe it fully there, so the decision was to move
> forward with the "partial" RFC rather than get bogged down in fully
> describing every facet of the feature before beginning implementation.
>
> As for the risk associated with this last stage of the restore
> redundancy feature, as far as I can tell, it's very low. The core changes
> are already in the 1.13 release branch, and have been since mid May, with
> no issues found since then. The proposed changes to be backported to the
> 1.13 release branch merely expose the REST endpoints associated with those
> changes, and don't touch core Geode at all, as far as I'm aware.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 2:09 PM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Add REST command for Restore Redundancy to
> 1.13 (GEODE-8095)
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
>
> Our "critical fixes rule" notes that our quarterly release cadence
> ensures that there is always an upcoming release vehicle for new features
> -- we will be cutting support/1.14 in just a few weeks on Aug 3.  Can you
> make the case that this feature is critical to release sooner?  As I
> understand it this feature is just an optimization -- existing code can
> already use the rebalance API to restore redundancy, it just might take a
> little longer.
>
> That said, all you need is three votes, so make your case.  Especially
> as we are already 8 weeks past the branch cut of support/1.13, and
> hopefully getting very close to an RC1, concern about risk weighs on my
> mind more than the merits.  What level of testing has this been through?
> Does it touch core code?  You may be able to get the votes just by
> demonstrating that the risk is very low.
>
> I'm a +0 for this based on the information presented so far.
>
> On 6/26/20, 11:50 AM, "Donal Evans"  wrote:
>
> +1
>
> Although normally features wouldn't really count as "critical
> fixes" that would warrant inclusion after the release branch has been cut,
> in this case, the internal API and gfsh commands for restore redundancy are
> already in the release, and it makes much more sense to include the entire
> feature in one release rather than having a semi-complete feature in 1.13
> and forcing the REST component to wait for a later release.
> 
> 

Re: Fate of master branch

[Dave Barnes]

+1 if we can override git’s ‘master’ default and establish ‘develop’ in its 
place. Otherwise renaming to ‘main’ would solve the problem with the negative 
connotations.

NB: Mark, I think the 3-vote convention is just for back-ports to the 
release-branch. I don’t think of it as applying to a general discussion like 
this one.

> On Jun 26, 2020, at 9:42 AM, Anthony Baker  wrote:
> 
> By just do it, I assume you mean:
> 
> - Contact delete master where not needed
> - Rename master to main when needed
> - Contact INFRA to change the default branch
> - Update README and CI jobs as needed
> 
> Across *all* geode repos.
> 
> 
> Anthony
> 
> 
>> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
>> 
>> +1 to delete. No good reason to keep it that I know of. I think I am the 
>> third +1 with no -1s so just do it.
>> 
>> Thanks,
>> Mark
>> 
>>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
>>> 
>>> +1 to deleting. Given we tag everything properly on the other branches, I
>>> don't see the need for it either.
>>> 
>>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>>  wrote:
>>> 
 +1 for deleting master branch. An also for updating the wiki page about
 branching that Alberto pointed out.
 
 De: Bruce Schuchardt 
 Enviado: viernes, 26 de junio de 2020 17:37
 Para: dev@geode.apache.org 
 Asunto: Re: Fate of master branch
 
 Let's just delete it.  I need to do that in my own repos as well.
 
 On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
 
  Apologies if this has been addressed already and I missed it.  In
 keeping with other OSS projects, I believe it’s time we did something about
 removing the insensitive term master from Geode repositories.
 
  One choice a lot of projects appear to be going with is a simple
 rename from master • main.  In our own case, however, master isn’t really
 in use for anything vital.  We track releases with a tag and a branch to
 backport fixes to, and the develop branch is the “source of truth”
 latest-and-greatest version of the code.  We could thus simply delete
 master with no loss I’m aware of.  Any opinions?
 
  Thanks,
 
  Blake
 
 
 
>> 
> 

Re: [Proposal] Back-port doc fixes to support/1.13

[Dave Barnes]

That was quick - thanks, all. I'll proceed with the back-port of these 5
fixes.

On Mon, Jun 29, 2020 at 10:36 AM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Monday, June 29, 2020 10:35 AM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>
> +1
>
> On 6/29/20, 10:32 AM, "Jinmei Liao"  wrote:
>
> +1, yay to doc changes.
> ____
> From: Dave Barnes 
> Sent: Monday, June 29, 2020 10:30 AM
> To: dev@geode.apache.org 
> Subject: [Proposal] Back-port doc fixes to support/1.13
>
> These five doc changes correct doc bugs and format errors that have
> caused
> users pain. I propose that we back-port them to support/1.13:
>
> GEODE-8193: Broken link in statistics list
>
> GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
> character
>
> GEODE-8304: Better highlight steps for building documentation
>
> GEODE-8237: Add note about 'alter region' and cluster conf service in
> doc
>
>

[Proposal] Back-port doc fixes to support/1.13

[Dave Barnes]

These five doc changes correct doc bugs and format errors that have caused
users pain. I propose that we back-port them to support/1.13:

GEODE-8193: Broken link in statistics list

GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
character

GEODE-8304: Better highlight steps for building documentation

GEODE-8237: Add note about 'alter region' and cluster conf service in doc

Re: [Proposal] Back-port doc fixes to support/1.13

[Dave Barnes]

For completeness, GEODE-7519 was a typo, should have been GEODE-7518.

On Mon, Jun 29, 2020 at 10:44 AM Dave Barnes  wrote:

> That was quick - thanks, all. I'll proceed with the back-port of these 5
> fixes.
>
> On Mon, Jun 29, 2020 at 10:36 AM Donal Evans  wrote:
>
>> +1
>> 
>> From: Owen Nichols 
>> Sent: Monday, June 29, 2020 10:35 AM
>> To: dev@geode.apache.org 
>> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>>
>> +1
>>
>> On 6/29/20, 10:32 AM, "Jinmei Liao"  wrote:
>>
>> +1, yay to doc changes.
>> 
>> From: Dave Barnes 
>> Sent: Monday, June 29, 2020 10:30 AM
>> To: dev@geode.apache.org 
>> Subject: [Proposal] Back-port doc fixes to support/1.13
>>
>> These five doc changes correct doc bugs and format errors that have
>> caused
>> users pain. I propose that we back-port them to support/1.13:
>>
>> GEODE-8193: Broken link in statistics list
>>
>> GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
>> character
>>
>> GEODE-8304: Better highlight steps for building documentation
>>
>> GEODE-8237: Add note about 'alter region' and cluster conf service in
>> doc
>>
>>

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

If I understand correctly that the refactored version has already been
checked in and tested on `develop`, then we have enough approvals to add
this to 1.13.
Go ahead, Mark.

On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior  wrote:

> Yes, +1 on this change.
>
> Joris
> 
> From: Mark Hanson 
> Sent: June 15, 2020 16:30
> To: dev@geode.apache.org 
> Subject: Re: Refactor to Restore Redundancy Command for 1.13?
>
> To be clear the code for 1.13 using the Restore Redundancy Command in GFSH
> is fine as it stands. We are refactoring to add the REST API version.
>
> Are people still good with that?
>
> Thanks,
> Mark
>
> On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
>
> +1 for getting the change into 1.13
>
> On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols 
> wrote:
>
> > +1 for getting it right the first time
> >
> >
> > ---
> > Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cjmelchior%40vmware.com%7C9d6cf31bdd97492b191808d8116ae982%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637278498191299129sdata=7pw0D4Xl2AYwFj%2BLn7apALTVw%2B5nZaVDP6Vkz0Nl4HU%3Dreserved=0
> >
> >
> > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson 
> > wrote:
> > Hi All,
> >
> > So we are working on refactoring the Restore Redundancy gfsh command
> code
> > and we have made a change to a class that is getting serialized. We
> are
> > curious if this is something we could maybe get into 1.13 ( the first
> > release of this command? Or should we just make our
> > serialization/deserialization work for 2 versions?
> >
> > Thanks,
> > Mark
> >
>
>

Re: [PROPOSAL] back port fix for GEODE-8251 to support branches

[Dave Barnes]

OK to backport, Jinmei. Thanks for your contribution.
-Dave

(I saw a +1 vote from Owen in another email client, though it doesn’t seem to 
show up in this rendering of the thread. Thought I had successfully worked 
around the email issue. Hmmm…)

> On Jun 19, 2020, at 8:47 AM, Jianxia Chen  wrote:
> 
> +1
> 
> On Fri, Jun 19, 2020 at 8:46 AM Jinmei Liao  wrote:
> 
>> Need one more vote 
>> 
>> From: Bruce Schuchardt 
>> Sent: Thursday, June 18, 2020 3:43 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] back port fix for GEODE-8251 to support branches
>> 
>> +1
>> 
>> On 6/18/20, 3:24 PM, "Jinmei Liao"  wrote:
>> 
>>The fix for this issue
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8251data=02%7C01%7Cjiliao%40vmware.com%7C76cb38f955c84ade5d9f08d813d91e9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281170530289424sdata=a8fdpKs4MUwr90bE0oOgobk5so840TJhK47%2FJFE0JDs%3Dreserved=0
>> is needed on support 1.13 branch in order for rolling upgrade to work from
>> 1.12 to 1.13.
>> 
>>Thanks!
>> 
>>Jinmei
>> 
>> 

Re: [PROPOSAL] backport GEODE-8277 to support/1.13

[Dave Barnes]

Wow, +103! Sounds like an endorsement.

On Thu, Jun 18, 2020 at 12:44 PM Owen Nichols  wrote:

> +1
>
> On 6/18/20, 12:15 PM, "Dick Cavender"  wrote:
>
> +1
>
> -Original Message-
> From: Ernie Burghardt 
> Sent: Thursday, June 18, 2020 10:49 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] backport GEODE-8277 to support/1.13
>
> +100
>
> On 6/18/20, 10:46 AM, "Bruce Schuchardt"  wrote:
>
> Several keystores used by a test have expired, which will cause
> acceptance tests to fail in support/1.13.  I’d like to cherry-pick the new
> keystores into that branch.  The new keystores have a 5/2120 expiration
> date.
>
>
>

Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

[Dave Barnes]

Thanks for taking care of this, Naba.

> On Jun 19, 2020, at 12:27 PM, Nabarun Nag  wrote:
> 
> Thank you all for the  votes needed for the backport. It has been backported 
> to support/1.13 branch
> 
> GEODE-8261: Added a null check for the proxyID. (#5251)
> 
> Regards
> Naba
> 
> 
> -Original Message-
> From: Jianxia Chen  
> Sent: Friday, June 19, 2020 12:22 PM
> To: dev@geode.apache.org
> Subject: Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.
> 
> +1
> 
> On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag  wrote:
> 
>> Hi Geode devs,
>> 
>> Requesting vote to backport of GEODE-8261 to 1.13
>> 
>> Why?
>> This commit fixes an issue with servers throwing null pointer 
>> exceptions while a member is being shutdown and registering interest is in 
>> process.
>> 
>> SHA
>> 720a4caea2ddb22296aa3225fc5264d2096cdf20
>> 
>> 
>> Regards
>> Nabarun
>> 

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

Thanks for clarifying, Mark. Let's wait for all the approvals and test
results before back-porting to 1.13.


On Tue, Jun 16, 2020 at 2:16 PM Mark Hanson  wrote:

> Hi Dave,
>
> So this PR is actually awaiting some reviews before it will be put on
> develop.
>
> Thanks,
> Mark
>
> On 6/16/20, 2:07 PM, "Dave Barnes"  wrote:
>
> If I understand correctly that the refactored version has already been
> checked in and tested on `develop`, then we have enough approvals to
> add
> this to 1.13.
> Go ahead, Mark.
>
> On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior 
> wrote:
>
> > Yes, +1 on this change.
> >
> > Joris
> > 
> > From: Mark Hanson 
> > Sent: June 15, 2020 16:30
> > To: dev@geode.apache.org 
> > Subject: Re: Refactor to Restore Redundancy Command for 1.13?
> >
> > To be clear the code for 1.13 using the Restore Redundancy Command
> in GFSH
> > is fine as it stands. We are refactoring to add the REST API version.
> >
> > Are people still good with that?
> >
> > Thanks,
> > Mark
> >
> > On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
> >
> > +1 for getting the change into 1.13
> >
> > On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols <
> onich...@vmware.com>
> > wrote:
> >
> > > +1 for getting it right the first time
> > >
> > >
> > > ---
> > > Sent from Workspace ONE Boxer<
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Chansonm%40vmware.com%7C774b45ee83db4e6a5a5a08d812394116%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279384406586799sdata=vcdgVzwoT7OO7%2BJJC1s6U8VVO2lpg0rYFCLSMHR9Kq4%3Dreserved=0
> > >
> > >
> > > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson <
> hans...@vmware.com>
> > > wrote:
> > > Hi All,
> > >
> > > So we are working on refactoring the Restore Redundancy gfsh
> command
> > code
> > > and we have made a change to a class that is getting
> serialized. We
> > are
> > > curious if this is something we could maybe get into 1.13 (
> the first
> > > release of this command? Or should we just make our
> > > serialization/deserialization work for 2 versions?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> >
>
>

Re: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13

[Dave Barnes]

Looks like the community approves, Ju@n. Go ahead and merge.
Thanks,
Dave

On Wed, Jun 10, 2020 at 10:37 AM Joris Melchior 
wrote:

> +1
> 
> From: Ju@N 
> Sent: June 10, 2020 6:18
> To: dev@geode.apache.org 
> Subject: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13
>
> Hello devs,
>
> I'd like to propose bringing GEODE-8029 [1] to the *support/1.12* and
> *support/1.13* branches.
> The fix has been merged into develop through commit
> bc0090dc93643fd4d09c79a4b0c29d883172b546 [2], and it's basically to make
> sure we delete unused drfs upon initialization to prevent the proliferation
> of unused records and files within the file system, which could cause
> members to fail during startup while recovering disk-stores.
> Best regards.
>
> [1]:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601sdata=kw1jFlsIIdlhh%2FTxW%2BcZD2BVmfQzGSCgoW1xyRdKE4E%3Dreserved=0
> [2:]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fbc0090dc93643fd4d09c79a4b0c29d883172b546data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601sdata=R412kMw3EXKl6%2FOgKP3OEZDuJJs%2F3uRIT0AZljdlpDo%3Dreserved=0
>
> --
> Ju@N
>

Re: [PROPOSAL] backport GEODE-8238 to support/1.13

[Dave Barnes]

OK, Bruce -- merge away.
Thanks,
Dave

On Thu, Jun 11, 2020 at 12:47 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Eric Shu 
> Sent: Thursday, June 11, 2020 11:33 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] backport GEODE-8238 to support/1.13
>
> +1
> 
> From: Owen Nichols 
> Sent: Thursday, June 11, 2020 10:58 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] backport GEODE-8238 to support/1.13
>
> +1
>
>
> ---
> Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024080508sdata=3hgzE2ImoJR8lePkXCM307ob%2FVB7m4dyEcbxLA75laI%3Dreserved=0
> >
>
> On June 11, 2020 at 10:52:19 AM PDT, Bruce Schuchardt 
> wrote:
> This ticket concerns loss of a message and a subsequent hang during
> shutdown.  The problem is also in support/1.13 and I'd like to backport to
> that branch.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8238data=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024080508sdata=cG2rc2X1YAmsqGZVumT%2F4JLUYIH5hjm8Y%2Fw8ADIa6oQ%3Dreserved=0
>
> It's a small change to fix a problem introduced in changes for GEODE-7727.
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-7727data=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024085498sdata=xaYlc41o44RmSdwvko%2FuhBW6VtNvRgFXGAsRbU%2FY2YQ%3Dreserved=0
>
>

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Dave Barnes]

Suppose I want to commit to another contributor's fork. How can they grant
me permission to do so? (This is a common predicament for me when I'm
reviewing doc PRs.)


On Wed, Jun 3, 2020 at 2:04 PM Xiaojian Zhou  wrote:

> We have discussed that when in Common team. The current solution worked
> perfectly.
>
> One person will merge the develop into feature/GEODE-7665 (which
> conceptually can be anyone. I did 2 times) every week. Now Naba is taking
> the responsibility to do the weekly merge. He did great!
>
> Fork will cause many other issues, it will still need a person to maintain
> it. I feel fork is only suitable for a work that will be finished within a
> week.
>
> Regards
> Gester
>
> On 6/2/20, 4:41 PM, "Nabarun Nag"  wrote:
>
> I don’t think it is right to make the open source Geode Community to
> work on my personal fork
>
> Regards
> Naba
>
>
> -Original Message-
> From: Mark Hanson 
> Sent: Tuesday, June 2, 2020 4:35 PM
> To: dev@geode.apache.org
> Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> While I am not 100% sure, I understand your thoughts here, I am pretty
> sure I do. We have already done such work in a branch in a fork (Micrometer
> work). The only real gotcha was that there needed to be one person at least
> as a collaborator, in case of vacations and such.
>
> All of the things you have specified are possible within the confines
> of a fork.
>
> Thanks,
> Mark
>
> On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:
>
> - We are maintaining feature/GEODE-7665 which is the feature
> branch for PR clear work on which multiple developers are working on.
> - We are maintaining this in Geode repository.
> - All sub-tasks of GEODE-7665 are merged into this feature branch.
> - Anyone in the Geode community can work on any subtask
> - This is a long running, and a massive feature development which
> is manipulating core code on Apache Geode. Hence all work is pushed to the
> feature branch to keep develop isolated from a regression introduced in PR
> clear work.
> - We have previously used release flags for Lucene work which we
> found to be inefficient and unnecessary extra work.
>
> We vote that PR clear feature branch be maintained in the Geode
> Repository as this is a long running, massive effort involving everyone
> from the community.
>
> When the PR clear tasks are completed, the branch will be
> rigorously tested and then squash merged into develop and the feature
> branch will be deleted.
>
>
> Regards
> Naba
>
> -Original Message-
> From: Jacob Barrett 
> Sent: Tuesday, June 2, 2020 3:43 PM
> To: dev@geode.apache.org
> Subject: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> I know this has been brought up multiple times without resolution.
> I want us resolve to ban the use of Geode repository for work in progress,
> feature branches, or any other branches that are not release or support
> branches. There is no reason given the nature of GitHub why you can’t fork
> the repository to contribute.
>
> * Work done on these branches results in the ASF bots updating the
> associated JIRAs and email blasting all of us with your work.
>
> * People don’t clean up these branches, which leads to a mess of
> branches on everyones clones and in the UI.
>
> * All your intermediate commits get synced to the repo, which
> bloats the repo for everyone else. Even your commits you rebase over and
> force push are left in the repo. When you delete your branch these commits
> are not removed. There is no way for us to prune unreferenced commits.
> Nobody else needs your commits outside of what was merged to a production
> branch.
>
> If anyone has a use case for working directly from Geode repo that
> can’t work from a fork please post it here so we can resolve.
>
> Thanks,
> Jake
>
>
>
>
>
>

Re: [PROPOSAL] Cherry pic GEODE-8331 to support branches

[Dave Barnes]

Please go ahead, Jinmei. Thanks for your contribution.

On Wed, Jul 22, 2020 at 3:11 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Anilkumar Gingade 
> Sent: Wednesday, July 22, 2020 2:44 PM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] Cherry pic GEODE-8331 to support branches
>
> +1
> This will provide a consistent experience our end user from 1.10 release
> version.
>
> On 7/22/20, 2:23 PM, "Jinmei Liao"  wrote:
>
> I would like to propose to cherry pick GEODE-8331: allow GFSH to
> connect to other versions of cluster (#5375) to support branches up to
> 1.10. This would allow gfsh to connect to other versions of cluster and
> provide better error messages when command is not support by the connected
> cluster.
>
> Jinmei
>
>

[Proposal] Back-port doc fixes to support/1.13

[Dave Barnes]

I propose back-porting the following doc updates to Geode support/1.13 (and
1.12, while we're at it):


- GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove from
docs (code fixed in 1.9.0, docs fixed in 1.14.0)

- GEODE-7628: Block jmx mbean creation when no security manager is
configured (docs) (code fixed in 1.12.0, docs fixed in 1.14.0)

- GEODE-8308: Some formatting text visible in the docs (docs only, fixed in
1.14.0)

- GEODE-8363: Label Micrometer docs as experimental (docs only, fixed in
1.14.0)

- GEODE-8377: User Guide: GFSH GC command should be documented to use only
in non-production environments (docs only, fixed in 1.14.0)

Re: [PROPOSAL] Postpone Geode 1.14

[Dave Barnes]

+1

On Tue, Jul 28, 2020 at 5:05 PM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Tuesday, July 28, 2020 4:38 PM
> To: Alexander Murmann ; dev@geode.apache.org <
> dev@geode.apache.org>
> Subject: Re: [PROPOSAL] Postpone Geode 1.14
>
> +1
>
>
> ---
> Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cdoevans%40vmware.com%7Ccd4d1f981e344957f92a08d8334f6516%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637315763386093818sdata=Ydv6m8%2F2p6c342hpTp3HStbMDCqD3M4xJfFLjeMc1ZM%3Dreserved=0
> >
>
> On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann 
> wrote:
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the 1.14
> release. The actual ship date for Geode 1.13 is important information for
> that conversation. Thus we cannot have that conversation before then.
>

Re: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.

[Dave Barnes]

OK, Eric, go ahead. Thanks for your contribution!
Dave

On Tue, Jul 28, 2020 at 5:15 PM Donal Evans  wrote:

> +1
> 
> From: Dick Cavender 
> Sent: Tuesday, July 28, 2020 4:53 PM
> To: dev@geode.apache.org 
> Subject: RE: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.
>
> +1
>
> -Original Message-
> From: Eric Shu 
> Sent: Tuesday, July 28, 2020 4:22 PM
> To: dev@geode.apache.org
> Subject: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.
>
> This is to address HARegionQueue GII events not properly removed issue,
> which could potentially resurrect a strayed event in client cache.
>
> Regards,
> Eric
>

Re: [PROPOSAL] port GEODE-8385 changes to support/1.13

[Dave Barnes]

+1
Thanks, Bruce.

On Wed, Jul 29, 2020 at 8:22 AM Jianxia Chen  wrote:

> +1
>
> On Wed, Jul 29, 2020 at 8:04 AM Bruce Schuchardt 
> wrote:
>
> > This concerns a hang during recovery from disk.  The problem was
> > introduced in 1.13.
> >
> > https://issues.apache.org/jira/browse/GEODE-8385
> >
> >
>

Re: [Proposal] Back-port doc fixes to support/1.13

[Dave Barnes]

Thanks, y'all.

On Wed, Jul 22, 2020 at 5:01 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Owen Nichols 
> Sent: Wednesday, July 22, 2020 4:59 PM
> To: dev@geode.apache.org
> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>
>
>
>
> +1
>
> On July 22, 2020 at 3:43:16 PM PDT, Jinmei Liao  wrote:
> +1
>
> On Jul 22, 2020 3:39 PM, Dave Barnes  wrote:
> I propose back-porting the following doc updates to Geode support/1.13
> (and 1.12, while we're at it):
>
>
> - GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove
> from docs (code fixed in 1.9.0, docs fixed in 1.14.0)
>
> - GEODE-7628: Block jmx mbean creation when no security manager is
> configured (docs) (code fixed in 1.12.0, docs fixed in 1.14.0)
>
> - GEODE-8308: Some formatting text visible in the docs (docs only, fixed in
> 1.14.0)
>
> - GEODE-8363: Label Micrometer docs as experimental (docs only, fixed in
> 1.14.0)
>
> - GEODE-8377: User Guide: GFSH GC command should be documented to use only
> in non-production environments (docs only, fixed in 1.14.0)
>