-<div class="doc_subsection"> <a name="reviews">Code Reviews</a></div>
-<div class="doc_text">
- <p>LLVM has a code review policy. Code review is one way to increase the
- quality of software. We generally follow these policies:</p>
- <ol>
- <li>All developers are required to have significant changes reviewed
- before they are committed to the repository.</li>
- <li>Code reviews are conducted by email, usually on the llvm-commits
- list.</li>
- <li>Code can be reviewed either before it is committed or after. We expect
- major changes to be reviewed before being committed, but smaller
- changes (or changes where the developer owns the component) can be
- reviewed after commit.</li>
- <li>The developer responsible for a code change is also responsible for
- making all necessary review-related changes.</li>
- <li>Code review can be an iterative process, which continues until the patch
- is ready to be committed.</li>
- </ol>
+<h3><a name="reviews">Code Reviews</a></h3>
+<div>
+<p>LLVM has a code review policy. Code review is one way to increase the quality
+ of software. We generally follow these policies:</p>
+
+<ol>
+ <li>All developers are required to have significant changes reviewed before
+ they are committed to the repository.</li>
+
+ <li>Code reviews are conducted by email, usually on the llvm-commits
+ list.</li>
+
+ <li>Code can be reviewed either before it is committed or after. We expect
+ major changes to be reviewed before being committed, but smaller changes
+ (or changes where the developer owns the component) can be reviewed after
+ commit.</li>
+
+ <li>The developer responsible for a code change is also responsible for making
+ all necessary review-related changes.</li>
+
+ <li>Code review can be an iterative process, which continues until the patch
+ is ready to be committed.</li>
+</ol>
+
+<p>Developers should participate in code reviews as both reviewers and
+ reviewees. If someone is kind enough to review your code, you should return
+ the favor for someone else. Note that anyone is welcome to review and give
+ feedback on a patch, but only people with Subversion write access can approve
+ it.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h3><a name="owners">Code Owners</a></h3>
+<div>
+
+<p>The LLVM Project relies on two features of its process to maintain rapid
+ development in addition to the high quality of its source base: the
+ combination of code review plus post-commit review for trusted maintainers.
+ Having both is a great way for the project to take advantage of the fact that
+ most people do the right thing most of the time, and only commit patches
+ without pre-commit review when they are confident they are right.</p>
+
+<p>The trick to this is that the project has to guarantee that all patches that
+ are committed are reviewed after they go in: you don't want everyone to
+ assume someone else will review it, allowing the patch to go unreviewed. To
+ solve this problem, we have a notion of an 'owner' for a piece of the code.
+ The sole responsibility of a code owner is to ensure that a commit to their
+ area of the code is appropriately reviewed, either by themself or by someone
+ else. The current code owners are:</p>
+
+<ol>
+ <li><b>Evan Cheng</b>: Code generator and all targets.</li>
+
+ <li><b>Greg Clayton</b>: LLDB.</li>
+
+ <li><b>Doug Gregor</b>: Clang Frontend Libraries.</li>
+
+ <li><b>Howard Hinnant</b>: libc++.</li>
+
+ <li><b>Anton Korobeynikov</b>: Exception handling, debug information, and
+ Windows codegen.</li>
+
+ <li><b>Ted Kremenek</b>: Clang Static Analyzer.</li>
+
+ <li><b>Chris Lattner</b>: Everything not covered by someone else.</li>
+
+ <li><b>John McCall</b>: Clang LLVM IR generation.</li>
+
+ <li><b>Jakob Olesen</b>: Register allocators and TableGen.</li>
+
+ <li><b>Duncan Sands</b>: dragonegg and llvm-gcc 4.2.</li>
+
+ <li><b>Peter Collingbourne</b>: libclc.</li>
+
+ <li><b>Tobias Grosser</b>: polly.</li>
+</ol>