<ol>
<li>Attract both users and developers to the LLVM project.</li>
<li>Make life as simple and easy for contributors as possible.</li>
- <li>Keep the top of tree CVS/SVN trees as stable as possible.</li>
+ <li>Keep the top of Subversion trees as stable as possible.</li>
</ol>
<p>This policy is aimed at frequent contributors to LLVM. People interested in
<!--=========================================================================-->
<div class="doc_text">
<p>This section contains policies that pertain to frequent LLVM
- developers. We always welcome <a href="#patches">random patches</a> from
- people who do not routinely contribute to LLVM, but expect more from frequent
- contributors to keep the system as efficient as possible for everyone.
- Frequent LLVM contributors are expected to meet the following obligations in
+ 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>
<p>When making a patch for review, the goal is to make it as easy for the
reviewer to read it as possible. As such, we recommend that you:</p>
<ol>
- <li>Make your patch against the CVS HEAD (main development trunk),
- not a branch, and not an old version of LLVM. This makes it easy to
- apply the patch.</li>
+ <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>
<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:
- <pre>cvs diff -Ntdup -5</pre>
+ <pre>svn diff -x -u</pre>
or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read the
diff.</li>
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 the patch
+ <li>Code review can be an iterative process, which continues until the patch
is ready to be committed.</li>
</ol>
<p>Developers should participate in code reviews as both reviewers and
- a reviewees. If someone is kind enough to review your code, you should
+ 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>
+ and give feedback on a patch, but only people with Subversion write access
+ can approve it.</p>
</div>
bug being fixed or feature being implemented is in the llvm-gcc C++
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>
<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 your aren't required to.</p>
+but you aren't required to.</p>
</div>
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>
+ <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
<!--=========================================================================-->
<div class="doc_text">
- <p>This section addresses the issues of copyright and license for the LLVM
- project.
+ <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
<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 to others 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 base commercial development on llvm-gcc without
+ 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
projects / oota-llvm.git / blobdiff