LLVM RFC would split committers from reviewers, require owner OK

LLVM is weighing a major rewrite of who may land code and who may approve it. In an RFC on Discourse, Reid Kleckner proposes splitting today’s single committer role into two: committers, who can push branches and merge after approval, and a smaller reviewers group that alone can satisfy required code-owner checks.

Under the draft, becoming a committer would take only two merged pull requests a reviewer judges valuable. Reviewer status would be harder: three examples of helpful feedback, backed by two existing reviewers, one outside the applicant’s employer. Non-committers would be limited to one open pull request at a time, a nudge meant to push regular contributors toward commit access. Reviewers would own the whole tree via GitHub’s CODEOWNERS mechanism, with the project’s pull-request ruleset requiring their approval and listing only that team as able to bypass it.

Kleckner’s stated aims are practical. Repository write access unlocks GitHub features many contributors already want: the ordinary merge button, auto-merge when checks pass, and stacked pull requests that depend on user branches in the main repo. Separating landing rights from approving rights is meant to give those tools to active authors without handing every committer unilateral approval power, while the one-PR cap and higher reviewer bar are meant to cut low-quality drive-by work.

Reaction has been mixed. Several people like the committer/reviewer split in principle and compare it to WebKit’s model. Others flag gaps: large areas such as the Clang frontend and Flang barely use CODEOWNERS today, so mandatory owner approval would need coverage work first. GitHub also cannot enforce “merge only your own PR”; anyone with write can merge any ready change once checks pass. The single open-PR limit drew pushback as too harsh for people asked to split work, with suggestions of two or three instead.

Deeper worries center on bottlenecks and scope. Critics say the RFC goes well beyond an earlier thread that only sought to raise the committer bar, and that shrinking the set of people who can approve risks slowing busy components unless employers fund more review time. Others argue the project should grow reviewers through education rather than concentrate power in a select few. The draft policy text and access-request templates are already posted for comment.