On a repo I've been maintaining, I'm horribly tempted to revoke almost everyone's commit access, for two reasons: to add a code review step to the process, and to be able to keep the commit history reasonably clean.
It's low-tech, but a human gatekeeper's really your only hope for enforcing whatever conventions your project has.
It makes a lot of sense to require that a commit must go through at least 1-2 human reviewers before getting merged to master. In addition to going through automated builds and tests, if applicable.
You need more than one person who can commit to master and is responsible for the merges, but you most certainly don't need every contributor to have commit access.
- hiring developers that appreciate and obey the conventions, or
- reducing the weight of the conventions.
Simply put, if you have conventions that the developers aren't following, you're organization is dysfunctional in some way. Management should include the team when crafting the conventions, and management should take efforts to give the team time/resources to obey them.
Based on what I've seen from popular open-source Python projects I've used in the past (Fabric, Haystack and basically anything else by daniel lindsley) having a single human gatekeeper is the express lane to hell. If you do that make sure you have at least a few core contribs who can approve commits.
There are an awful lot of maintainers for smaller individual pieces/subsytems of the kernel. Take a look at the MAINTAINERS file to see who is responsible for the smaller chunks:
I've never even looked at any linux source code, but I still know there's too much of it to believe Linus reviews and signs off on every single commit personally.
It's low-tech, but a human gatekeeper's really your only hope for enforcing whatever conventions your project has.