Sorry this part was unclear…

The Chromium team does pre-commit reviews for all changes (with the exception of reverts due to broken changes and other minor exceptions).

Requiring up-front code reviews is a little slower in the short term, but it has huge advantages in the long-term:

• The psychological factor of knowing that someone is going to be looking at your change, and commenting on it on the public mailing list causes you to instinctually take more care in what you are doing.
• Reviews spread knowledge around the team of what is going on and how things work.
• Reviews help the team develop an informal understanding of who best knows what areas of code.
• Finally, the extra set of eyes on a change does frequently find bugs and opportunities for improvement.

In order for a change to land in Chrome, the author of the change needs to get a code review from another team member. The change also needs to either be in an area that the author is an “owner” of, or else the author needs to get a review from someone who is an owner of that area. The result of this process is that typically an engineer can commit with a single review, because typically engineers work in a specific area that they are an owner of. But engineers are still empowered to do wide-ranging refactors, with the constraint that they need to get an additional review from each area their change touches.