<li><a href="#incremental">Incremental Development</a></li>
<li><a href="#attribution">Attribution of Changes</a></li>
</ol></li>
- <li><a href="#candl">Copyright and License</a>
+ <li><a href="#clp">Copyright, License, and Patents</a>
<ol>
<li><a href="#copyright">Copyright</a></li>
<li><a href="#license">License</a></li>
<li><a href="#devagree">Developer Agreements</a></li>
</ol></li>
</ol>
-<div class="doc_author">Written by LLVM Oversight Team</div>
+<div class="doc_author">Written by the LLVM Oversight Team</div>
<!--=========================================================================-->
<div class="doc_section"><a name="introduction">Introduction</a></div>
<li>Keep the top of tree CVS/SVN trees as stable as possible.</li>
</ol>
- <p>This policy is aimed at regular contributors to LLVM. People interested in
+ <p>This policy is aimed at frequent contributors to LLVM. People interested in
contributing one-off patches can do so in an informal way by sending them to
the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
llvm-commits mailing list</a> and engaging another developer to see it through
<div class="doc_section"><a name="policies">Developer Policies</a></div>
<!--=========================================================================-->
<div class="doc_text">
- <p>This section contains policies that pertain generally to regular LLVM
- developers. We always welcome <a href="#patches">random patches</a> from
- people who do not routinely contribute to LLVM, but expect more from regular
- contributors to keep the system as efficient as possible for everyone.
- Regular LLVM developers are expected to meet the following obligations in
+ <p>This section contains policies that pertain to frequent LLVM
+ developers. We always welcome <a href="#patches">one-off patches</a> from
+ people who do not routinely contribute to LLVM, but we expect more from
+ frequent contributors to keep the system as efficient as possible for
+ everyone.
+ Frequent LLVM contributors are expected to meet the following requirements in
order for LLVM to maintain a high standard of quality.<p>
</div>
<tt>utils/mkpatch</tt> utility takes care of this for you.</li>
</ol>
+
+ <p>When sending a patch to a mailing list, it is a good idea to send it as an
+ <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>
</div>
<!-- _______________________________________________________________________ -->
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 goes until all the patch
+ <li>Code review can be an iterative process, which continues until the patch
is ready to be committed.</li>
- <li>Developers should participate in code reviews as both a reviewer and
- a reviewee. We don't have a dedicated team of reviewers. If someone is
- kind enough to review your code, you should return the favor for someone
- else.</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 CVS write access can
+ approve it.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
<div class="doc_text">
<p>Developers are required to create test cases for any bugs fixed and any new
- features added. The following policies apply:</p>
+ features added. Some tips for getting your testcase approved:</p>
<ol>
- <li>All feature and regression test cases must be added to the
+ <li>All feature and regression test cases are added to the
<tt>llvm/test</tt> directory. The appropriate sub-directory should be
selected (see the <a href="TestingGuide.html">Testing Guide</a> for
details).</li>
<a href="LangRef.html">LLVM assembly language</a> unless the
feature or regression being tested requires another language (e.g. the
bug being fixed or feature being implemented is in the llvm-gcc C++
- front-end).</li>
+ front-end, in which case it must be written in C++).</li>
<li>Test cases, especially for regressions, should be reduced as much as
- possible, by <a href="CommandGuide/html/bugpoint.html">bugpoint</a> or
+ possible, by <a href="Bugpoint.html">bugpoint</a> or
manually. It is unacceptable
to place an entire failing program into <tt>llvm/test</tt> as this creates
a <i>time-to-test</i> burden on all developers. Please keep them short.</li>
- <li>More extensive test cases (applications, benchmarks, etc.) should be
- added to the <tt>llvm-test</tt> test suite. This test suite is for
- coverage: not features or regressions.</li>
</ol>
+
+ <p>Note that llvm/test is designed for regression and small feature tests
+ only. More extensive test cases (e.g., entire applications, benchmarks,
+ etc) should be added to the <tt>llvm-test</tt> test suite. The llvm-test
+ suite is for coverage (correctness, performance, etc) testing, not feature
+ or regression testing.</p>
</div>
<!-- _______________________________________________________________________ -->
<li>Bug fixes and new features should <a href="#testcases">include a
testcase</a> so we know if the fix/feature ever regresses in the
future.</li>
- <li>Code must pass the dejagnu (llvm/test) test suite.</li>
+ <li>Code must pass the dejagnu (<tt>llvm/test</tt>) test suite.</li>
<li>The code must not cause regressions on a reasonable subset of llvm-test,
where "reasonable" depends on the contributor's judgement and the scope
of the change (more invasive changes require more testing). A reasonable
<p>Additionally, the committer is responsible for addressing any problems
found in the future that the change is responsible for. For example:</p>
<ul>
- <li>The code should compile cleanly on all platforms.</li>
- <li>The changes should not cause regressions in the <tt>llvm-test</tt>
- suite including SPEC CINT2000, SPEC CFP2000, SPEC CINT2006, and
- SPEC CFP2006.</li>
+ <li>The code should compile cleanly on all supported platforms.</li>
+ <li>The changes should not cause any correctness regressions in the
+ <tt>llvm-test</tt> suite and must not cause any major performance
+ regressions.</li>
<li>The change set should not cause performance or correctness regressions
for the LLVM tools.</li>
<li>The changes should not cause performance or correctness regressions in
bugs</a> that result from your change.</li>
</ul>
- <p>We prefer for this to be handled before submission but understand that it's
- not possible to test all of this for every submission. Our nightly testing
+ <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>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
llvm-commits</a>. When approved you may commit it yourself.</li>
<li>You are allowed to commit patches without approval which you think are
- obvious. This is clearly a subjective decision. We simply expect you to
- use good judgement. Examples include: fixing build breakage, reverting
+ obvious. This is clearly a subjective decision — we simply expect you
+ to use good judgement. Examples include: fixing build breakage, reverting
obviously broken patches, documentation/comment changes, any other minor
changes.</li>
<li>You are allowed to commit patches without approval to those portions
- of LLVM that you have contributed or maintain (have been assigned
+ of LLVM that you have contributed or maintain (i.e., have been assigned
responsibility for), with the proviso that such commits must not break the
build. This is a "trust but verify" policy and commits of this nature are
reviewed after they are committed.</li>
<li>Multiple violations of these policies or a single egregious violation
may cause commit access to be revoked.</li>
</ol>
+
+<p>In any case, your changes are still subject to <a href="#reviews">code
+review</a> (either before or after they are committed, depending on the nature
+of the change). You are encouraged to review other peoples' patches as well,
+but you aren't required to.</p>
</div>
<div class="doc_text">
<p>When a developer begins a major new project with the aim of contributing
it back to LLVM, s/he should inform the community with an email to
- the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvm-dev</a>
+ the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
email list, to the extent possible. The reason for this is to:
<ol>
<li>keep the community informed about future changes to LLVM, </li>
- <li>avoid duplication of effort by having multiple parties working on the
- same thing and not knowing about it, and</li>
+ <li>avoid duplication of effort by preventing multiple parties working on
+ the same thing and not knowing about it, and</li>
<li>ensure that any technical issues around the proposed work are
discussed and resolved before any significant work is done.</li>
</ol>
<p>The design of LLVM is carefully controlled to ensure that all the pieces
fit together well and are as consistent as possible. If you plan to make a
- major change to the way LLVM works or
- a major new extension, it is a good idea to get consensus with the development
+ major change to the way LLVM works or want to add a major new extension, it
+ is a good idea to get consensus with the development
community before you start working on it.</p>
<p>Once the design of the new feature is finalized, the work itself should be
<li>Often, an independent precursor to a big change is to add a new API and
slowly migrate clients to use the new API. Each change to use the new
API is often "obvious" and can be committed without review. Once the
- new API is in place and used, it is often easy to replace the underlying
- implementation of the API.</li>
+ new API is in place and used, it is much easier to replace the
+ underlying implementation of the API. This implementation change is
+ logically separate from the API change.</li>
</ul>
<p>If you are interested in making a large change, and this scares you, please
make sure to first <a href="#newwork">discuss the change/gather
- consensus</a> then feel free to ask about the best way to go about making
+ consensus</a> then ask about the best way to go about making
the change.</p>
</div>
<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="#candl">copyright</a>: it is only used to attribute the file to
+ 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. Revision control keeps an accurate history of contributions.</li>
+ 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/cvsweb/cvsweb.cgi/llvm/CREDITS.TXT?rev=HEAD&content-type=text/x-cvsweb-markup">CREDITS.txt</a>
file to summarize their contributions.</li>
<!--=========================================================================-->
-<div class="doc_section"><a name="candl">Copyright and License</a></div>
+<div class="doc_section">
+ <a name="clp">Copyright, License, and Patents</a>
+</div>
<!--=========================================================================-->
<div class="doc_text">
- <p>We address here the issues of copyright and license for the LLVM project.
- The object of the copyright and license is the LLVM source code and
- documentation.
+ <p>This section addresses the issues of copyright, license and patents for
+ the LLVM project.
Currently, the University of Illinois is the LLVM copyright holder and the
terms of its license to LLVM users and developers is the
<a href="http://www.opensource.org/licenses/UoI-NCSA.php">University of
- Illinois/NCSA Open Source License</a>.
+ Illinois/NCSA Open Source License</a>.</p>
<div class="doc_notes">
<p><b>NOTE: This section deals with legal matters but does not provide
- official legal advice. We are not lawyers, please seek legal counsel from an
+ legal advice. We are not lawyers, please seek legal counsel from an
attorney.</b></p>
</div>
-
</div>
<!-- _______________________________________________________________________ -->
read the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">License</a>
if further clarification is needed.</p>
- <p>Note that the LLVM Project does distribute some code that includes GPL
- software (notably, llvm-gcc which is based on the GCC GPL source base).
- This means that anything "linked" into to llvm-gcc must itself be compatible
+ <p>Note that the LLVM Project does distribute llvm-gcc, <b>which is GPL.</b>
+ This means that anything "linked" into llvm-gcc must itself be compatible
with the GPL, and must be releasable under the terms of the GPL. This implies
- that you <b>any code linked into llvm-gcc and distributed may be subject to
- the viral aspects of the GPL</b>. This is not a problem for the main LLVM
- distribution (which is already licensed under a more liberal license), but may
- be a problem if you intend to do commercial development without redistributing
- your source code.</p>
+ that <b>any code linked into llvm-gcc and distributed to others may be subject
+ to the viral aspects of the GPL</b> (for example, a proprietary code generator
+ linked into llvm-gcc must be made available under the GPL). This is not a
+ problem for code already distributed under a more liberal license (like the
+ UIUC license), and does not affect code generated by llvm-gcc. It may be a
+ problem if you intend to base commercial development on llvm-gcc without
+ redistributing your source code.</p>
<p>We have no plans to change the license of LLVM. If you have questions
or comments about the license, please contact the <a
<p>To the best of our knowledge, LLVM does not infringe on any patents (we have
actually removed code from LLVM in the past that was found to infringe).
- Having code in LLVM that infringes on patents would violate the one of the
- goals of the project by making it hard or impossible to reuse the code for
- arbitrary purposes.</p>
+ Having code in LLVM that infringes on patents would violate an important
+ goal of the project by making it hard or impossible to reuse the code for
+ 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
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
- Written by: the
+ 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$
projects / oota-llvm.git / blobdiff