Re: errors from logging code in unit tests

2021-02-25 Thread Bruce Schuchardt
Every "distributed" unit test I've run lately has had it.  I just tried 
ClusterCommunicationsDUnitTest. createEntryAndVerifyUpdate(), for instance, and 
see these ERRORs in the output.  For some reason the test runner ignores these 
messages and the tests pass.

On 2/24/21, 4:07 PM, "Udo Kohlmeyer"  wrote:

What test(s) are you running? Version?

--Udo

On 2/25/21, 8:39 AM, "Ernie Burghardt"  wrote:

Its not just you Bruce, I get this...
2021-02-24 13:38:10,891 main ERROR Error processing element 
GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 13:38:10,898 main ERROR Error processing element 
GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 13:38:10,898 main ERROR Error processing element 
GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 13:38:10,933 main ERROR Appenders contains an invalid 
element or attribute "GeodeAlert"
2021-02-24 13:38:10,954 main ERROR Unable to locate appender "STDOUT" 
for logger config "root"
2021-02-24 13:38:10,954 main ERROR Unable to locate appender 
"LOGWRITER" for logger config "root"
2021-02-24 13:38:10,955 main ERROR Unable to locate appender "ALERT" 
for logger config "root"
2021-02-24 13:38:10,956 main ERROR Unable to locate appender 
"SECURITYLOGWRITER" for logger config "org.apache.geode.security"
waiting for views to stabilize
sending SerialAckedMessage from m1 to m2

On 2/24/21, 1:30 PM, "Bruce Schuchardt"  wrote:

This has started showing up in all of my test runs.  Is anyone else 
seeing it?  Maybe something in my environment?

2021-02-24 11:19:44,765 main ERROR Error processing element 
GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 11:19:44,778 main ERROR Error processing element 
GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 11:19:44,779 main ERROR Error processing element 
GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND
2021-02-24 11:19:44,805 main ERROR Appenders contains an invalid 
element or attribute "GeodeAlert"
2021-02-24 11:19:44,819 main ERROR Unable to locate appender 
"STDOUT" for logger config "root"
2021-02-24 11:19:44,820 main ERROR Unable to locate appender 
"LOGWRITER" for logger config "root"
2021-02-24 11:19:44,820 main ERROR Unable to locate appender 
"ALERT" for logger config "root"
2021-02-24 11:19:44,820 main ERROR Unable to locate appender 
"SECURITYLOGWRITER" for logger config "org.apache.geode.security"





Concourse access

2021-02-25 Thread Mario Salazar de Torres
Hi everyone,
I am trying to access one of the jobs for the geode-native concourse pipeline 
(I.E: https://concourse.apachegeode-ci.info/builds/7105), but the only thing I 
can see is a loading message. Do I need any read permissions?
If that's the case, this is my GitHub username is 'gaussianrecurrence'

BR,
Mario


Geode Native Tooling

2021-02-25 Thread Jacob Barrett
Hey Geode Native devs,

You may have noticed this new CI that looks a lot like the Java CI. PRs will 
now be executed against this CI and several platforms. All unit and integration 
tests are executed on all the platforms as well. It also takes over the tasks 
of the old Travis CI of validating your sources for formatting, license and 
static analysis for correctness.

https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop

The clang-format and clang-tidy tools used by the CI have been upgraded to 
clang 11. When checking locally please make sure your clang-tidy and 
clang-format detected by CMake is version 11. There are some slight formatting 
differences between clang-format 11 and the previous version 6. The new 
clang-tidy also detects things that version 6 did not detect.


Thanks,
Jake



Re: Geode Native Tooling

2021-02-25 Thread Mario Salazar de Torres
Hi Jacob,

No words to describe what a huge effort you put into this. I think it's really 
going to ease verification work for everyone in the future.
However, today I was running one PR on Concourse and I noticed that Windows 
2019 job was failing. Could it be that there are some details to polish for 
that pipeline?

BR,
Mario.

From: Jacob Barrett 
Sent: Thursday, February 25, 2021 6:04 PM
To: dev@geode.apache.org 
Subject: Geode Native Tooling

Hey Geode Native devs,

You may have noticed this new CI that looks a lot like the Java CI. PRs will 
now be executed against this CI and several platforms. All unit and integration 
tests are executed on all the platforms as well. It also takes over the tasks 
of the old Travis CI of validating your sources for formatting, license and 
static analysis for correctness.

https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop

The clang-format and clang-tidy tools used by the CI have been upgraded to 
clang 11. When checking locally please make sure your clang-tidy and 
clang-format detected by CMake is version 11. There are some slight formatting 
differences between clang-format 11 and the previous version 6. The new 
clang-tidy also detects things that version 6 did not detect.


Thanks,
Jake



Re: code-owners seems to have some problems

2021-02-25 Thread Mark Hanson
Hi Owen,

Is there a way to ensure that draft mode PRs aren't requesting reviews from 
code owners?

Thanks,
Mark

On 2/19/21, 11:44 AM, "Owen Nichols"  wrote:

GitHub provides some tools to answer this kind of question.

Step 1: Under the PR's "Files Changed" tab, click File Filter > Your 
CODEOWNER files
Step 2: Hover over the keyhole/shield icon (to the left of the red/green 
changecount graphic to the left of each filename) to see who else is also owner.
Step 3: If the ownership doesn't seem quite right, click on the 
keyhole/shield icon to see the exact line in CODEOWNERS that was applied.

Please note, if a file has NO codeowner, it will still show up in the "Your 
CODEOWNER files" (but no keyhole/shield indicator will be displayed).  It would 
be fantastic to find owners for these remaining unowned files, but until then 
owned-by-no-one == owned-by-everyone.

Improvements to CODEOWNERS can always be submitted via PR.

Some files in your list below have no owner, but several are owned by 
someone else so they shouldn't be showing up in your list.  Perhaps you 
copy&pasted this list from the Jump To dropdown?  If so, it seems that a File 
Filter selection does not filter the Jump To dropdown, only the display below.

On 2/19/21, 11:30 AM, "Bruce Schuchardt"  wrote:

I was pulled in to PR 5989 but can’t figure out how that happened with 
the current CODEOWNERS file.  These all seem out of my area:

boms/geode-all-bom/src/test/resources/expected-pom.xml
  
buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy
 extensions/geode-modules-session/build.gradle
 extensions/geode-modules/build.gradle
  extensions/geode-modules/src/test/resources/expected-pom.xml
 extensions/session-testing-war/build.gradle
  
...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java
   
geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java
 
...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java
  
...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java
 
.../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java
  
...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java
  geode-assembly/src/integrationTest/resources/assembly_content.txt
 geode-assembly/src/integrationTest/resources/dependency_classpath.txt
 
.../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java
 geode-core/build.gradle
  
...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
  
geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java




Re: code-owners seems to have some problems

2021-02-25 Thread Owen Nichols
GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs 
(until you mark it not-draft by clicking Ready For Review).  However if you 
subsequently change it back to a draft, GitHub will not remove any reviewers.

On 2/25/21, 10:28 AM, "Mark Hanson"  wrote:

Hi Owen,

Is there a way to ensure that draft mode PRs aren't requesting reviews from 
code owners?

Thanks,
Mark

On 2/19/21, 11:44 AM, "Owen Nichols"  wrote:

GitHub provides some tools to answer this kind of question.

Step 1: Under the PR's "Files Changed" tab, click File Filter > Your 
CODEOWNER files
Step 2: Hover over the keyhole/shield icon (to the left of the 
red/green changecount graphic to the left of each filename) to see who else is 
also owner.
Step 3: If the ownership doesn't seem quite right, click on the 
keyhole/shield icon to see the exact line in CODEOWNERS that was applied.

Please note, if a file has NO codeowner, it will still show up in the 
"Your CODEOWNER files" (but no keyhole/shield indicator will be displayed).  It 
would be fantastic to find owners for these remaining unowned files, but until 
then owned-by-no-one == owned-by-everyone.

Improvements to CODEOWNERS can always be submitted via PR.

Some files in your list below have no owner, but several are owned by 
someone else so they shouldn't be showing up in your list.  Perhaps you 
copy&pasted this list from the Jump To dropdown?  If so, it seems that a File 
Filter selection does not filter the Jump To dropdown, only the display below.

On 2/19/21, 11:30 AM, "Bruce Schuchardt"  wrote:

I was pulled in to PR 5989 but can’t figure out how that happened 
with the current CODEOWNERS file.  These all seem out of my area:

boms/geode-all-bom/src/test/resources/expected-pom.xml
  
buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy
 extensions/geode-modules-session/build.gradle
 extensions/geode-modules/build.gradle
  extensions/geode-modules/src/test/resources/expected-pom.xml
 extensions/session-testing-war/build.gradle
  
...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java
   
geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java
 
...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java
  
...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java
 
.../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java
  
...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java
  geode-assembly/src/integrationTest/resources/assembly_content.txt
 
geode-assembly/src/integrationTest/resources/dependency_classpath.txt
 
.../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java
 geode-core/build.gradle
  
...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
  
geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java





Re: code-owners seems to have some problems

2021-02-25 Thread Mark Hanson
Hi Owen, 

Two more questions.
Is it the case that only one of the code owners for that area has to review the 
PR?
Also, is there a way to tell that a code owner has reviewed an area, so you 
don't have to as one of the other code owners?

Thanks,
Mark

On 2/25/21, 10:31 AM, "Owen Nichols"  wrote:

GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs 
(until you mark it not-draft by clicking Ready For Review).  However if you 
subsequently change it back to a draft, GitHub will not remove any reviewers.

On 2/25/21, 10:28 AM, "Mark Hanson"  wrote:

Hi Owen,

Is there a way to ensure that draft mode PRs aren't requesting reviews 
from code owners?

Thanks,
Mark

On 2/19/21, 11:44 AM, "Owen Nichols"  wrote:

GitHub provides some tools to answer this kind of question.

Step 1: Under the PR's "Files Changed" tab, click File Filter > 
Your CODEOWNER files
Step 2: Hover over the keyhole/shield icon (to the left of the 
red/green changecount graphic to the left of each filename) to see who else is 
also owner.
Step 3: If the ownership doesn't seem quite right, click on the 
keyhole/shield icon to see the exact line in CODEOWNERS that was applied.

Please note, if a file has NO codeowner, it will still show up in 
the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). 
 It would be fantastic to find owners for these remaining unowned files, but 
until then owned-by-no-one == owned-by-everyone.

Improvements to CODEOWNERS can always be submitted via PR.

Some files in your list below have no owner, but several are owned 
by someone else so they shouldn't be showing up in your list.  Perhaps you 
copy&pasted this list from the Jump To dropdown?  If so, it seems that a File 
Filter selection does not filter the Jump To dropdown, only the display below.

On 2/19/21, 11:30 AM, "Bruce Schuchardt"  wrote:

I was pulled in to PR 5989 but can’t figure out how that 
happened with the current CODEOWNERS file.  These all seem out of my area:

boms/geode-all-bom/src/test/resources/expected-pom.xml
  
buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy
 extensions/geode-modules-session/build.gradle
 extensions/geode-modules/build.gradle
  extensions/geode-modules/src/test/resources/expected-pom.xml
 extensions/session-testing-war/build.gradle
  
...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java
   
geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java
 
...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java
  
...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java
 
.../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java
  
...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java
  
geode-assembly/src/integrationTest/resources/assembly_content.txt
 
geode-assembly/src/integrationTest/resources/dependency_classpath.txt
 
.../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java
 geode-core/build.gradle
  
...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
  
geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java






Re: Geode Native Tooling

2021-02-25 Thread Ernie Burghardt
Aka different versions of clang-format are not compatible in a sense...  also, 
watch out for non-standard clang-format versions that may come with certain 
IDEs...

On 2/25/21, 9:04 AM, "Jacob Barrett"  wrote:

Hey Geode Native devs,

You may have noticed this new CI that looks a lot like the Java CI. PRs 
will now be executed against this CI and several platforms. All unit and 
integration tests are executed on all the platforms as well. It also takes over 
the tasks of the old Travis CI of validating your sources for formatting, 
license and static analysis for correctness.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cburghardte%40vmware.com%7C205541686f0144b8d73b08d8d9af6f7a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498694801612706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L1X4YxLX14MVjti%2FIpvMgU%2FS0nWzJ5bN87fsuTN9Q10%3D&reserved=0

The clang-format and clang-tidy tools used by the CI have been upgraded to 
clang 11. When checking locally please make sure your clang-tidy and 
clang-format detected by CMake is version 11. There are some slight formatting 
differences between clang-format 11 and the previous version 6. The new 
clang-tidy also detects things that version 6 did not detect.


Thanks,
Jake




Re: Geode Native Tooling

2021-02-25 Thread Jacob Barrett
Running the legacy tests on windows is still flaky. Windows!

> On Feb 25, 2021, at 9:46 AM, Mario Salazar de Torres 
>  wrote:
> 
> Hi Jacob,
> 
> No words to describe what a huge effort you put into this. I think it's 
> really going to ease verification work for everyone in the future.
> However, today I was running one PR on Concourse and I noticed that Windows 
> 2019 job was failing. Could it be that there are some details to polish for 
> that pipeline?
> 
> BR,
> Mario.
> 
> From: Jacob Barrett 
> Sent: Thursday, February 25, 2021 6:04 PM
> To: dev@geode.apache.org 
> Subject: Geode Native Tooling
> 
> Hey Geode Native devs,
> 
> You may have noticed this new CI that looks a lot like the Java CI. PRs will 
> now be executed against this CI and several platforms. All unit and 
> integration tests are executed on all the platforms as well. It also takes 
> over the tasks of the old Travis CI of validating your sources for 
> formatting, license and static analysis for correctness.
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cjabarrett%40vmware.com%7Cac0f398338d7416dfc5808d8d9b55faa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498720303119021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMHK1Yxe1axWH6wCUHG6y%2F2%2By8t%2Fl6dDFMzBoWkL1Sk%3D&reserved=0
> 
> The clang-format and clang-tidy tools used by the CI have been upgraded to 
> clang 11. When checking locally please make sure your clang-tidy and 
> clang-format detected by CMake is version 11. There are some slight 
> formatting differences between clang-format 11 and the previous version 6. 
> The new clang-tidy also detects things that version 6 did not detect.
> 
> 
> Thanks,
> Jake
> 



RE: Geode Native Tooling

2021-02-25 Thread Alberto Bustamante Reyes
Very good news for the native client. Thanks for the improvement Jacob!

BR/

Alberto B.

De: Jacob Barrett 
Enviado: jueves, 25 de febrero de 2021 20:49
Para: dev@geode.apache.org 
Asunto: Re: Geode Native Tooling

Running the legacy tests on windows is still flaky. Windows!

> On Feb 25, 2021, at 9:46 AM, Mario Salazar de Torres 
>  wrote:
>
> Hi Jacob,
>
> No words to describe what a huge effort you put into this. I think it's 
> really going to ease verification work for everyone in the future.
> However, today I was running one PR on Concourse and I noticed that Windows 
> 2019 job was failing. Could it be that there are some details to polish for 
> that pipeline?
>
> BR,
> Mario.
> 
> From: Jacob Barrett 
> Sent: Thursday, February 25, 2021 6:04 PM
> To: dev@geode.apache.org 
> Subject: Geode Native Tooling
>
> Hey Geode Native devs,
>
> You may have noticed this new CI that looks a lot like the Java CI. PRs will 
> now be executed against this CI and several platforms. All unit and 
> integration tests are executed on all the platforms as well. It also takes 
> over the tasks of the old Travis CI of validating your sources for 
> formatting, license and static analysis for correctness.
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cjabarrett%40vmware.com%7Cac0f398338d7416dfc5808d8d9b55faa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498720303119021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMHK1Yxe1axWH6wCUHG6y%2F2%2By8t%2Fl6dDFMzBoWkL1Sk%3D&reserved=0
>
> The clang-format and clang-tidy tools used by the CI have been upgraded to 
> clang 11. When checking locally please make sure your clang-tidy and 
> clang-format detected by CMake is version 11. There are some slight 
> formatting differences between clang-format 11 and the previous version 6. 
> The new clang-tidy also detects things that version 6 did not detect.
>
>
> Thanks,
> Jake
>



Re: Concourse access

2021-02-25 Thread Jacob Barrett
I made the pipelines public. If you want more access than that let us know. 
Before that though can you give me a sense for the usability of the public 
access on the pipelines?

Thanks,
Jake


> On Feb 25, 2021, at 8:31 AM, Mario Salazar de Torres 
>  wrote:
> 
> Hi everyone,
> I am trying to access one of the jobs for the geode-native concourse pipeline 
> (I.E: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F7105&data=04%7C01%7Cjabarrett%40vmware.com%7Ce185d8a90bbc465b627d08d8d9aac74f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637498674804124104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i3BkZhXIcGAPBlyv0%2BoSCYhCEUzr%2BpLOM4nZj416kYY%3D&reserved=0),
>  but the only thing I can see is a loading message. Do I need any read 
> permissions?
> If that's the case, this is my GitHub username is 'gaussianrecurrence'
> 
> BR,
> Mario



Re: code-owners seems to have some problems

2021-02-25 Thread Robert Houghton
Hi Mark,

Yes, each area of ownership only needs one review-by-owner.
Your following question, I do not understand, but I'll try: Any PR that needs 
review, will have text in the "reviewers needed and status-required" area, that 
states who is still needed to review. However, there is not a direct way to see 
if a co-owner has already reviewed a file you are looking at.

-Robert

On 2/25/21, 10:36 AM, "Mark Hanson"  wrote:

Hi Owen, 

Two more questions.
Is it the case that only one of the code owners for that area has to review 
the PR?
Also, is there a way to tell that a code owner has reviewed an area, so you 
don't have to as one of the other code owners?

Thanks,
Mark

On 2/25/21, 10:31 AM, "Owen Nichols"  wrote:

GitHub does not add reviewers from CODEOWNERS to PRs created as draft 
PRs (until you mark it not-draft by clicking Ready For Review).  However if you 
subsequently change it back to a draft, GitHub will not remove any reviewers.

On 2/25/21, 10:28 AM, "Mark Hanson"  wrote:

Hi Owen,

Is there a way to ensure that draft mode PRs aren't requesting 
reviews from code owners?

Thanks,
Mark

On 2/19/21, 11:44 AM, "Owen Nichols"  wrote:

GitHub provides some tools to answer this kind of question.

Step 1: Under the PR's "Files Changed" tab, click File Filter > 
Your CODEOWNER files
Step 2: Hover over the keyhole/shield icon (to the left of the 
red/green changecount graphic to the left of each filename) to see who else is 
also owner.
Step 3: If the ownership doesn't seem quite right, click on the 
keyhole/shield icon to see the exact line in CODEOWNERS that was applied.

Please note, if a file has NO codeowner, it will still show up 
in the "Your CODEOWNER files" (but no keyhole/shield indicator will be 
displayed).  It would be fantastic to find owners for these remaining unowned 
files, but until then owned-by-no-one == owned-by-everyone.

Improvements to CODEOWNERS can always be submitted via PR.

Some files in your list below have no owner, but several are 
owned by someone else so they shouldn't be showing up in your list.  Perhaps 
you copy&pasted this list from the Jump To dropdown?  If so, it seems that a 
File Filter selection does not filter the Jump To dropdown, only the display 
below.

On 2/19/21, 11:30 AM, "Bruce Schuchardt"  
wrote:

I was pulled in to PR 5989 but can’t figure out how that 
happened with the current CODEOWNERS file.  These all seem out of my area:

boms/geode-all-bom/src/test/resources/expected-pom.xml
  
buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy
 extensions/geode-modules-session/build.gradle
 extensions/geode-modules/build.gradle
  
extensions/geode-modules/src/test/resources/expected-pom.xml
 extensions/session-testing-war/build.gradle
  
...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java
   
geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java
 
...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java
  
...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java
 
.../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java
  
...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java
  
geode-assembly/src/integrationTest/resources/assembly_content.txt
 
geode-assembly/src/integrationTest/resources/dependency_classpath.txt
 
.../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java
 geode-core/build.gradle
  
...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
  
geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java







Re: Concourse access

2021-02-25 Thread Mario Salazar de Torres
Hi Jacob,

In my case, I can see now both geode-native-develop and geode-native-develop-pr 
set of pipelines, but when I try to see any execution of any of its pipelines I 
am stuck at the loading message. Interestingly I've noticed that one of the 
underlying requests sent 
(https://concourse.apachegeode-ci.info/api/v1/builds/7105/plan) returns 403, so 
maybe I am missing still some permissions?

BR,
Mario.

From: Jacob Barrett 
Sent: Thursday, February 25, 2021 9:55 PM
To: dev@geode.apache.org 
Subject: Re: Concourse access

I made the pipelines public. If you want more access than that let us know. 
Before that though can you give me a sense for the usability of the public 
access on the pipelines?

Thanks,
Jake


> On Feb 25, 2021, at 8:31 AM, Mario Salazar de Torres 
>  wrote:
>
> Hi everyone,
> I am trying to access one of the jobs for the geode-native concourse pipeline 
> (I.E: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F7105&data=04%7C01%7Cjabarrett%40vmware.com%7Ce185d8a90bbc465b627d08d8d9aac74f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637498674804124104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i3BkZhXIcGAPBlyv0%2BoSCYhCEUzr%2BpLOM4nZj416kYY%3D&reserved=0),
>  but the only thing I can see is a loading message. Do I need any read 
> permissions?
> If that's the case, this is my GitHub username is 'gaussianrecurrence'
>
> BR,
> Mario



Re: code-owners seems to have some problems

2021-02-25 Thread Mark Hanson
Hi Robert,

Thanks! You answered the question the way I intended.

Thanks,
Mark

On 2/25/21, 12:57 PM, "Robert Houghton"  wrote:

Hi Mark,

Yes, each area of ownership only needs one review-by-owner.
Your following question, I do not understand, but I'll try: Any PR that 
needs review, will have text in the "reviewers needed and status-required" 
area, that states who is still needed to review. However, there is not a direct 
way to see if a co-owner has already reviewed a file you are looking at.

-Robert

On 2/25/21, 10:36 AM, "Mark Hanson"  wrote:

Hi Owen, 

Two more questions.
Is it the case that only one of the code owners for that area has to 
review the PR?
Also, is there a way to tell that a code owner has reviewed an area, so 
you don't have to as one of the other code owners?

Thanks,
Mark

On 2/25/21, 10:31 AM, "Owen Nichols"  wrote:

GitHub does not add reviewers from CODEOWNERS to PRs created as 
draft PRs (until you mark it not-draft by clicking Ready For Review).  However 
if you subsequently change it back to a draft, GitHub will not remove any 
reviewers.

On 2/25/21, 10:28 AM, "Mark Hanson"  wrote:

Hi Owen,

Is there a way to ensure that draft mode PRs aren't requesting 
reviews from code owners?

Thanks,
Mark

On 2/19/21, 11:44 AM, "Owen Nichols"  
wrote:

GitHub provides some tools to answer this kind of question.

Step 1: Under the PR's "Files Changed" tab, click File 
Filter > Your CODEOWNER files
Step 2: Hover over the keyhole/shield icon (to the left of 
the red/green changecount graphic to the left of each filename) to see who else 
is also owner.
Step 3: If the ownership doesn't seem quite right, click on 
the keyhole/shield icon to see the exact line in CODEOWNERS that was applied.

Please note, if a file has NO codeowner, it will still show 
up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be 
displayed).  It would be fantastic to find owners for these remaining unowned 
files, but until then owned-by-no-one == owned-by-everyone.

Improvements to CODEOWNERS can always be submitted via PR.

Some files in your list below have no owner, but several 
are owned by someone else so they shouldn't be showing up in your list.  
Perhaps you copy&pasted this list from the Jump To dropdown?  If so, it seems 
that a File Filter selection does not filter the Jump To dropdown, only the 
display below.

On 2/19/21, 11:30 AM, "Bruce Schuchardt" 
 wrote:

I was pulled in to PR 5989 but can’t figure out how 
that happened with the current CODEOWNERS file.  These all seem out of my area:

boms/geode-all-bom/src/test/resources/expected-pom.xml
  
buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy
 extensions/geode-modules-session/build.gradle
 extensions/geode-modules/build.gradle
  
extensions/geode-modules/src/test/resources/expected-pom.xml
 extensions/session-testing-war/build.gradle
  
...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java
   
geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java
 
...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java
  
...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java
 
.../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java
  
...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java
  
geode-assembly/src/integrationTest/resources/assembly_content.txt
 
geode-assembly/src/integrationTest/resources/dependency_classpath.txt
 
.../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java
 geode-core/build.gradle
  
...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
  
geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java








Re: [VOTE] Apache Geode 1.12.1.RC4

2021-02-25 Thread Owen Nichols
It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 4 binding votes
* Dick Cavender (PMC member)
* John Blum (PMC member)
* Dave Barnes (PMC member)
* Robert Houghton (PMC member)
* Donal Evans

+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.12.1.RC4 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen Nichols


On 2/24/21, 10:34 AM, "Dave Barnes"  wrote:

+1
Docs.
- Geode API docs header correctly updated to 1.12.1
- User guide build scripts generated correct 1.12.1 manual
- Native client user guides built correctly
- Native client api docs not tested -- they're generated by the full
software build, so I assume they're OK. We publish only the latest version
(1.13) on the Apache Geode website.

On Mon, Feb 22, 2021 at 10:23 AM Robert Houghton 
wrote:

> +1
>
> I verified the version.properties file contents to match the pipeline
> version that we've tested and verified.
> -Robert Houghton
>
>
> On 2/21/21, 12:08 PM, "Owen Nichols"  wrote:
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.1.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 Thu, February 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.1.RC4
>
> Release notes:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2Oli0NZ%2FidveHD4sACL%2BB076IKBMC4tWCOXr8u9SYIY%3D&reserved=0
>
> Source and binary distributions:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.1.RC4%2F&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fp%2Bfe74hYiYC5lHwK95%2BVh1eFy9bS6kpP5ijR7yOQ9I%3D&reserved=0
>
> Maven staging repo:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1075&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hcHUuLYYyNym7kX1xrc3TV%2BcLIl8LLhFyrM4GgKZMI4%3D&reserved=0
>
> GitHub:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TtmpXgSKX6lNeun1XJPuMWPXG%2FwfRgxMKWd8ikjDhHA%3D&reserved=0
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HvHDHpZQpG5%2F3PILgxICazAJXYiu1IeD3qZ1UGQzUsU%3D&reserved=0
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848694605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oV9pdJb5xTavMmYjXgUgqNGSjqc8gPGNv9Pe5ODhyTk%3D&reserved=0
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848694605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lC2B09NNk7JdslKnW%2BpYILC%2BQSHYARDzGUSwTJ

Passed: apache/geode-examples#527 (rel/v1.12.1 - 75ead25)

2021-02-25 Thread Travis CI
Build Update for apache/geode-examples
-

Build: #527
Status: Passed

Duration: 22 mins and 59 secs
Commit: 75ead25 (rel/v1.12.1)
Author: Owen Nichols
Message: Revert "temporarily point to staging repo for CI purposes"

View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.12.1

View the full build log and details: 
https://travis-ci.com/github/apache/geode-examples/builds/218309776?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Passed: apache/geode-native#3060 (rel/v1.12.1 - ba8fd9b)

2021-02-25 Thread Travis CI
Build Update for apache/geode-native
-

Build: #3060
Status: Passed

Duration: 1 hr, 17 mins, and 34 secs
Commit: ba8fd9b (rel/v1.12.1)
Author: Owen Nichols
Message: Bumping copyright year to 2021

View the changeset: https://github.com/apache/geode-native/compare/rel/v1.12.1

View the full build log and details: 
https://travis-ci.com/github/apache/geode-native/builds/218309781?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Broken: apache/geode-native#3062 (support/1.12 - 3e855a8)

2021-02-25 Thread Travis CI
Build Update for apache/geode-native
-

Build: #3062
Status: Broken

Duration: 3 mins and 19 secs
Commit: 3e855a8 (support/1.12)
Author: Owen Nichols
Message: Bumping Geode version to 1.12.1 for CI

View the changeset: 
https://github.com/apache/geode-native/compare/22f5b37de679...3e855a83bea5

View the full build log and details: 
https://travis-ci.com/github/apache/geode-native/builds/218315955?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.