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" <onich...@vmware.com> 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" <hans...@vmware.com> 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" <onich...@vmware.com> 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" <bru...@vmware.com> 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




Reply via email to