"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
time the patch was created and the time it is applied.</li>
- <li>Patches should be made with this command:
-<div class="doc_code">
-<pre>
-svn diff -x -u
-</pre>
-</div>
- or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read
- the diff.</li>
+ <li>Patches should be made with <tt>svn diff</tt>, or similar. If you use
+ a different tool, make sure it uses the <tt>diff -u</tt> format and
+ that it doesn't contain clutter which makes it hard to read.</li>
- <li>Patches should not include differences in generated code such as the code
- generated by <tt>autoconf</tt> or <tt>tblgen</tt>. The
- <tt>utils/mkpatch</tt> utility takes care of this for you.</li>
+ <li>If you are modifying generated files, such as the top-level
+ <tt>configure</tt> script, please separate out those changes into
+ a separate patch from the rest of your changes.</li>
</ol>
<p>When sending a patch to a mailing list, it is a good idea to send it as an
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>Ted Kremenek</b>: Clang Static Analyzer.</li>
- <li><b>Evan Cheng</b>: Code generator and all targets.</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