<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
<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>
<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>
+ 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
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 <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