"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>LLVM Developer Policy</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<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
<li>Patches should be made with this command:
<div class="doc_code">
<pre>
-svn diff -x -u
+svn diff
</pre>
</div>
or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read
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
</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
<p>We intend to keep LLVM perpetually open source and to use a liberal open
source license. The current license is the
<a href="http://www.opensource.org/licenses/UoI-NCSA.php">University of
- llinois/NCSA Open Source License</a>, which boils down to this:</p>
+ Illinois/NCSA Open Source License</a>, which boils down to this:</p>
<ul>
<li>You can freely distribute LLVM.</li>
projects / oota-llvm.git / blobdiff