SIG == special interest groups. https://www.kubernetes.dev/docs/guide/owners/
- Basically if any folders have independent codes, they may have their own OWNERS files with approvers and reviewers section
- if code changes are confined to such folders, then a PR can be merged if one of the approver from that folder's OWNERS approves it (and other conditions like tox etc. passes).
- For code that are NOT confined to such folders, both parents(could be root) OWNERS and current folders OWNERS files should be considered and approvals for both the approver groups should be present to mark a pr
can be merged
a sigowner should not be able to approve their own PR, just like we have it currently for approvers.
.
├── OWNERS
├── file1
├── file2
├── folder1
│ ├── OWNERS
│ ├── folder1_1
│ └── folder1_2
│ └── OWNERS
└── folder2
In this above examples. file1, file2 would have approvers from the root OWNERS file.
anything under folder1 and folder1_1 only would have approvers from folder1's OWNERS file+root OWNERS file, while approvers for folder1_2 would be: folder1's OWNERS file+root OWNERS file+ it's own OWNERS file. folder 2 will only have approvers from the root OWNERS file, as it does not have any OWNERS.
As long as one approver from the list approves the PR, it should be mergable.
SIG == special interest groups. https://www.kubernetes.dev/docs/guide/owners/
can be mergeda sigowner should not be able to approve their own PR, just like we have it currently for approvers.
In this above examples. file1, file2 would have approvers from the root OWNERS file.
anything under folder1 and folder1_1 only would have approvers from folder1's OWNERS file+root OWNERS file, while approvers for folder1_2 would be: folder1's OWNERS file+root OWNERS file+ it's own OWNERS file. folder 2 will only have approvers from the root OWNERS file, as it does not have any OWNERS.
As long as one approver from the list approves the PR, it should be mergable.