diff options
Diffstat (limited to 'docs/DeveloperPolicy.html')
| -rw-r--r-- | docs/DeveloperPolicy.html | 27 |
1 files changed, 18 insertions, 9 deletions
diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 13a908e..4986606 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -99,7 +99,9 @@ <ol> <li>Make your patch against the Subversion trunk, not a branch, and not an old - version of LLVM. This makes it easy to apply the patch.</li> + version of LLVM. This makes it easy to apply the patch. For information + on how to check out SVN trunk, please see the <a + href="GettingStarted.html#checkout">Getting Started Guide</a>.</li> <li>Similarly, patches should be submitted soon after they are generated. Old patches may not apply correctly if the underlying code changes between the @@ -185,14 +187,18 @@ svn diff else. The current code owners are:</p> <ol> + <li><b>Evan Cheng</b>: Code generator and all targets.</li> + + <li><b>Doug Gregor</b>: Clang Basic, Lex, Parse, and Sema Libraries.</li> + <li><b>Anton Korobeynikov</b>: Exception handling, debug information, and Windows codegen.</li> - <li><b>Duncan Sands</b>: llvm-gcc 4.2.</li> - - <li><b>Evan Cheng</b>: Code generator and all targets.</li> + <li><b>Ted Kremenek</b>: Clang Static Analyzer.</li> - <li><b>Chris Lattner</b>: Everything else.</li> + <li><b>Chris Lattner</b>: Everything not covered by someone else.</li> + + <li><b>Duncan Sands</b>: llvm-gcc 4.2.</li> </ol> <p>Note that code ownership is completely different than reviewers: anyone can @@ -287,9 +293,12 @@ svn diff </ul> <p>We prefer for this to be handled before submission but understand that it - isn't possible to test all of this for every submission. Our nightly testing - infrastructure normally finds these problems. A good rule of thumb is to - check the nightly testers for regressions the day after your change.</p> + isn't possible to test all of this for every submission. Our build bots and + nightly testing infrastructure normally finds these problems. A good rule of + thumb is to check the nightly testers for regressions the day after your + change. Build bots will directly email you if a group of commits that + included yours caused a failure. You are expected to check the build bot + messages to see if they are your fault and, if so, fix the breakage.</p> <p>Commits that violate these quality standards (e.g. are very broken) may be reverted. This is necessary when the change blocks other developers from @@ -592,7 +601,7 @@ Changes</a></div> Written by the <a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a><br> <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-06-15 04:18:54 +0000 (Mon, 15 Jun 2009) $ + Last modified: $Date: 2009-10-10 23:37:16 +0200 (Sat, 10 Oct 2009) $ </address> </body> </html> |
