Skip to content

Supporting sig-ownership of repositories #621

@dbasunag

Description

@dbasunag

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions