TiDB code owners Proposal

#1

Background

Why set up code owners?

As is well known, pingcap/tidb is a monorepo that contains various components/modules. Due to the vastness of the tidb codebase and the complexity of its components:

From the community’s perspective, different components/modules are maintained by different interest groups (‘SIG’).

Regarding reviewers and committers:

Currently, tidb’s review/commit permissions are granted at the granularity of the entire repository. This means that any reviewer and committer can commit code for all of tidb. With the increasing code volume and complexity of tidb, previous approach has led to many undesirable cases: a codebase managed by one component/module can be modified by reviewers/committers from other components/modules, and if unexpected issues or bugs arise, the responsibility still falls on the corresponding components/modules. In this sense, the current mechanism does not provide equal accountability and rights for components.

Based on this, we hope to introduce code owners to the tidb repository and achieve the following goal: Modifications to a certain module should at least be reviewed and approved by the corresponding module’s owners.

Rights and obligations

  1. Decision on whether PR can be merged.
  2. Nomination and maintenance of Approvers and reviewers.
  3. Promote test quality governance and CI execution efficiency governance.
  4. Introduce third-party supply chain review and decision-making.

Governance rules

  1. At least 2 members are required as the code owners of a module for easy backup.

  2. Who can be a code owner of a folder or path.

    1. Principle only active committers or maintainers listed in the community members ( list source ) can be designated as code owners.
    2. Code owners are designated by each component owner from maintainers and committers ( list source ).
    3. If candidate code owner is not in the maintainers and committers list( list source ), he or she need to be promoted from reviewers to committers role firstly.

  3. Member maintenance

    1. Code owners are maintained in repository /OWNERS_ALIASES files.
    2. When a code owner retired, the community list is retained but needs to be deleted from the code owners group in repository /OWNERS_ALIASES files.
    3. How to handle organizational adjustments/project adjustments.
      • When code owners change is involved, the original code owners submit PR to update the list in the /OWNERS_ALIASES file.

  4. Module control

    1. The first-level directory of the repository is initially established by EE according to the code owners assigned by repo owners.
    2. Subsequent secondary and finer levels are controlled by the code owner to establish finer OWNERS files as needed.
      • Adding and updating OWNERS files requires the approval of the original code owners or upper-level code owners or repo owners.

Driven solutions

Using the mechanism core of the kubernetes project, the overall scheme mechanism is mostly the same as the previous tidb configuration change control pre-audit scheme.

  1. Each repository uses the /OWNERS_ALIASES file for member maintenance, and maintenance members are the responsibility of the code owners of the repository.

    aliases:
  sig-approvers-xxx:
    - code-owner-1
    - code-owner-2   

  sig-approvers-yyy:
    - code-owner-3
    - code-owner-4

  2. Each repository creates an OWNERS file in the module directory and specifies approvers using the group defined in the /OWNERS_ALIASES file.

    • The OWNERS file in the directory should be configured with the no_parent_owners option enabled and the reviewers value not configured. So the reviewers in this directory will inherit from the reviewersand approvers in the parent directory.
    • If there is no OWNERS file in the directory ( OWNERS files in subdirectories do not count), use the simple configuration format:
      # See the OWNERS docs at https://go.k8s.io/owners
options:
  no_parent_owners: true
labels:
  - area/tidb-xxx
approvers:
  - sig-approvers-xxx
    • If the OWNERS file created by the configuration change prefix mechanism already exists in the directory, use the full configuration format:
        # See the OWNERS docs at https://go.k8s.io/owners
options:
  no_parent_owners: true

filters:
  "(OWNERS|config\\.go|config\\.toml\\.example)$":
    approvers:
      - sig-tidb- .....
  ".*": # default
    approvers:
      - sig-approvers-xxx
    labels:
      - area/tidb-xxx

  3. After the contributor submits the pull request, all changed scopes need to be approved. After that, the bot will add an approved label on it(one of the necessary conditions for auto merging).

[Announcement] introduce and deploy reviewing and approving mechanism for `pingcap/kvproto` repo
#2

We will track the process in issue: https://github.com/pingcap/tidb/issues/46911

#3

Could you provide some context about why we need to change the code owners? what are the issues we are encountering?

#4

Updates at 2023-09-25: added “Background” chapter and updated “Governance rules” chapter.

#5

I have updated it, PTAL