Re: Is the documentation wrong here?

2019-06-05 Thread liyuj
my login name is liyuj 在 2019/6/5 下午11:57, Dave Barnes 写道: @liyuj Do you have a login for the Apache JIRA system? Here's where you go to create a new ticket: https://issues.apache.org/jira/projects/GEODE/issues/GEODE-6803?filter=allopenissues On Tue, Jun 4, 2019 at 10:27 AM Dave Barnes wrote:

Re: [DISCUSS] require reviews before merging a PR

2019-06-05 Thread Alexander Murmann
> > If we trust committers, why review at all? Just commit... and we might > catch a problem, we might not. Honestly that to me would be the ideal state. However, our test coverage and code quality is nowhere near to allow for that. What I was referring to is different though. I didn't say "trust

Re: [DISCUSS] require reviews before merging a PR

2019-06-05 Thread Udo Kohlmeyer
Alexander, thank you for your response. And yes, change is uncomfortable and in some cases more reviewers would not have caught issues. BUT, more people would have seen the code, maybe become more familiar with it, etc... I don't say don't trust committers, as I am one. But I also know that I

Re: [DISCUSS] require reviews before merging a PR

2019-06-05 Thread Alexander Murmann
Udo, I agree with many of the pains you are addressing, but am pessimistic that having more reviewers will solve them. You are absolutely correct in calling out that the code is ugly complex and missing coverage. The best way to address this is to clean up the code and improve coverage. You say yo

Re: [DISCUSS] require reviews before merging a PR

2019-06-05 Thread Udo Kohlmeyer
@Kirk, I totally understand the pain that you speak of. I too agree that every line of changed code should have a test confirming that behavior was not changed. I don't believe that we need to go as far as revoking committer rights and reviewing each committer again, BUT it would be AMAZING th

Re: Static Analysis Tools such as SonarQube or others?

2019-06-05 Thread Charlie Black
Recommend run them all - It will at least enable the broader community to work on what is most important to them. On Wed, Jun 5, 2019 at 7:58 AM Peter Tran wrote: > From Dan: > >So I think an approach of cleaning up and enforcing one rule at a time is > better than just generating a report with

Re: Is the documentation wrong here?

2019-06-05 Thread Dave Barnes
@liyuj Do you have a login for the Apache JIRA system? Here's where you go to create a new ticket: https://issues.apache.org/jira/projects/GEODE/issues/GEODE-6803?filter=allopenissues On Tue, Jun 4, 2019 at 10:27 AM Dave Barnes wrote: > @liyuj Congratulations on finding a Geode doc bug. To get

Re: Static Analysis Tools such as SonarQube or others?

2019-06-05 Thread Peter Tran
>From Dan: >So I think an approach of cleaning up and enforcing one rule at a time is better than just generating a report with a bunch of rule violations. Yes - Love this idea! On Tue, Jun 4, 2019 at 4:46 PM Charlie Black wrote: > I used SonarQube on a project it helped the team where to foc

Re: Geode self-protection about overload

2019-06-05 Thread Alberto Gomez
Hi again, I finally figured out why I was not getting the "ServerConnectivityException" when executing a big amount of functions in Geode while I did get the exception when running lots of gets/puts/queries. The reason is that the ConnectionImpl::execute(Op op) does not use the timeout set by

Re: [DISCUSS] require reviews before merging a PR

2019-06-05 Thread Alberto Bustamante Reyes
my two cents (although Im a newcomer here): I agree with Kirk in the point that if a PR is sent by a committer, if after "grace period" (one/two weeks?) no one reviewed it, the author could merge it. But of course he/she is free to wait for a review. I was thinking about PRs made by contribut