<li><a href="#informed">Stay Informed</a></li>
<li><a href="#patches">Making a Patch</a></li>
<li><a href="#reviews">Code Reviews</a></li>
+ <li><a href="#owners">Code Owners</a></li>
<li><a href="#testcases">Test Cases</a></li>
<li><a href="#quality">Quality</a></li>
<li><a href="#commitaccess">Obtaining Commit Access</a></li>
<em>attachment</em> to the message, not embedded into the text of the
message. This ensures that your mailer will not mangle the patch when it
sends it (e.g. by making whitespace changes or by wrapping lines).</p>
+
+ <p><em>For Thunderbird users:</em> Before submitting a patch, please open
+ <em>Preferences → Advanced → General → Config Editor</em>,
+ find the key <tt>mail.content_disposition_type</tt>, and set its value to
+ <tt>1</tt>. Without this setting, Thunderbird sends your attachment using
+ <tt>Content-Disposition: inline</tt> rather than <tt>Content-Disposition:
+ attachment</tt>. Apple Mail gamely displays such a file inline, making it
+ difficult to work with for reviewers using that program.</p>
+</p>
</div>
<!-- _______________________________________________________________________ -->
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"> <a name="owners">Code Owners</a></div>
+<div class="doc_text">
+
+ <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>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>Chris Lattner</b>: Everything else.</li>
+ </ol>
+
+ <p>Note that code ownership is completely different than reviewers: anyone can
+ review a piece of code, and we welcome code review from anyone who is
+ interested. Code owners are the "last line of defense" to guarantee that
+ all patches that are committed are actually reviewed.</p>
+
+ <p>Being a code owner is a somewhat unglamorous position, but it is incredibly
+ important for the ongoing success of the project. Because people get busy,
+ interests change, and unexpected things happen, code ownership is purely
+ opt-in, and anyone can choose to resign their "title" at any time. For now,
+ we do not have an official policy on how one gets elected to be a code
+ owner.
+ </p>
+
+</div>
+
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
<div class="doc_text">
<div class="doc_text">
<p>We believe in correct attribution of contributions to
their contributors. However, we do not want the source code to be littered
- with random attributions (this is noisy/distracting and revision control
- keeps a perfect history of this anyway). As such, we follow these rules:</p>
- <ol>
- <li>Developers who originate new files in LLVM should place their name at
- the top of the file per the
- <a href="CodingStandards.html#scf_commenting">Coding Standards</a>.</li>
- <li>There should be only one name at the top of the file and it should be
- the person who created the file.</li>
- <li>Placing your name in the file does not imply <a
- href="#clp">copyright</a>: it is only used to attribute the file to
- its original author.</li>
- <li>Developers should be aware that after some time has passed, the name at
- the top of a file may become meaningless as maintenance/ownership of files
- changes. Despite this, once set, the attribution of a file never changes.
- Revision control keeps an accurate history of contributions.</li>
- <li>Developers should maintain their entry in the
- <a href="http://llvm.org/svn/llvm-project/llvm/trunk/CREDITS.TXT">CREDITS.txt</a>
- file to summarize their contributions.</li>
- <li>Commit comments should contain correct attribution of the person who
- submitted the patch if that person is not the committer (i.e. when a
- developer with commit privileges commits a patch for someone else).</li>
- </ol>
+ with random attributions "this code written by J Random Guy" (this is noisy
+ and distracting. In practice, the revision control system keeps a perfect
+ history of who change what, and the CREDITS.txt file describes higher-level
+ contributions.</p>
+
+ <p>Overall, please do not add contributor names to the source base.</p>
</div>
<p>
Although UIUC may eventually reassign the copyright of the software to another
- entity (e.g. a dedicated non-profit "LLVM Organization", or something)
+ entity (e.g. a dedicated non-profit "LLVM Organization")
the intent for the project is to always have a single entity hold the
copyrights to LLVM at any given time.</p>
reduces the managerial burden for any kind of administrative or technical
decisions about LLVM. The goal of the LLVM project is to always keep the code
open and <a href="#license">licensed under a very liberal license</a>.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<ul>
<li>You can freely distribute LLVM.</li>
<li>You must retain the copyright notice if you redistribute LLVM.</li>
- <li>Binaries derived from LLVM must reproduce the copyright notice.</li>
+ <li>Binaries derived from LLVM must reproduce the copyright notice (e.g.
+ in an included readme file).</li>
<li>You can't use our names to promote your LLVM derived products.</li>
<li>There's no warranty on LLVM at all.</li>
</ul>
arbitrary purposes (including commercial use).</p>
<p>When contributing code, we expect contributors to notify us of any potential
- for patent-related trouble with their changes. If you own the rights to a
+ for patent-related trouble with their changes. If you or your employer
+ own the rights to a
patent and would like to contribute code to LLVM that relies on it, we
- require that you sign an agreement that allows any other user of LLVM to
+ require that
+ the copyright owner sign an agreement that allows any other user of LLVM to
freely use your patent. Please contact the <a
href="mailto:llvm-oversight@cs.uiuc.edu">oversight group</a> for more
details.</p>
the entire software base can be managed by a single copyright holder. This
implies that any contributions can be licensed under the license that the
project uses.</p>
+
+ <p>When contributing code, you also affirm that you are legally entitled to
+ grant this copyright, personally or on behalf of your employer. If the code
+ belongs to some other entity, please raise this issue with the oversight
+ group before the code is committed.</p>
</div>
<!-- *********************************************************************** -->
projects / oota-llvm.git / blobdiff