2007-02-13 09:06:01 +00:00
|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
|
|
|
|
"http://www.w3.org/TR/html4/strict.dtd">
|
|
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<title>LLVM Developer Policy</title>
|
|
|
|
|
<link rel="stylesheet" href="llvm.css" type="text/css">
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<div class="doc_title">LLVM Developer Policy</div>
|
|
|
|
|
<ol>
|
2007-02-14 07:22:19 +00:00
|
|
|
<li><a href="#introduction">Introduction</a></li>
|
2007-02-13 09:06:01 +00:00
|
|
|
<li><a href="#general">General Policies</a>
|
|
|
|
|
<ol>
|
|
|
|
|
<li><a href="#informed">Stay Informed</a> </li>
|
|
|
|
|
<li><a href="#reviews">Code Reviews</a></li>
|
|
|
|
|
<li><a href="#testcases">Test Cases</a></li>
|
2007-02-19 05:49:11 +00:00
|
|
|
<li><a href="#quality">Quality</a></li>
|
|
|
|
|
<li><a href="#commitaccess">Obtaining Commit Access</a></li>
|
2007-02-19 05:43:04 +00:00
|
|
|
<li><a href="#newwork">Making a Major Change</a>
|
|
|
|
|
<ol>
|
|
|
|
|
<li><a href="#incremental">Incremental Development</a></li>
|
|
|
|
|
</ol></li>
|
|
|
|
|
<li><a href="#attribution">Attribution of Changes</a></li>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol></li>
|
|
|
|
|
<li><a href="#patches">Patch Policies</a>
|
|
|
|
|
<ol>
|
|
|
|
|
<li><a href="#p_form">Patch Form</a></li>
|
|
|
|
|
<li><a href="#p_submission">Patch Submission</a></li>
|
2007-02-14 17:20:59 +00:00
|
|
|
<li><a href="#p_aftersub">After Submission</a></li>
|
|
|
|
|
<li><a href="#p_aftercommit">After Commit</a></li>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol></li>
|
2007-02-14 07:22:19 +00:00
|
|
|
<li><a href="#candl">Copyright and License</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>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol>
|
|
|
|
|
<div class="doc_author">Written by LLVM Oversight Team</div>
|
|
|
|
|
|
|
|
|
|
<!--=========================================================================-->
|
2007-02-14 17:24:04 +00:00
|
|
|
<div class="doc_section"><a name="introduction">Introduction</a></div>
|
2007-02-13 09:06:01 +00:00
|
|
|
<!--=========================================================================-->
|
|
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>This document contains the LLVM Developer Policy which defines the
|
2007-02-13 17:04:09 +00:00
|
|
|
project's policy towards developers and their contributions. The intent of
|
2007-02-13 09:06:01 +00:00
|
|
|
this policy is to eliminate mis-communication, rework, and confusion that
|
|
|
|
|
might arise from the distributed nature of LLVM's development. By stating
|
|
|
|
|
the policy in clear terms, we hope each developer can know ahead of time
|
|
|
|
|
what to expect when making LLVM contributions.</p>
|
2007-02-14 22:55:40 +00:00
|
|
|
<p>This policy is also designed to accomplish the following objectives:</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Attract both users and developers to the LLVM project.</li>
|
|
|
|
|
<li>Make life as simple and easy for contributors as possible.</li>
|
2007-02-19 03:50:31 +00:00
|
|
|
<li>Keep the top of tree CVS/SVN trees as stable as possible.</li>
|
2007-02-14 22:55:40 +00:00
|
|
|
</ol>
|
2007-02-19 05:43:04 +00:00
|
|
|
|
|
|
|
|
<p>This policy is aimed at regular 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
|
|
|
|
|
the process.</p>
|
|
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!--=========================================================================-->
|
|
|
|
|
<div class="doc_section"><a name="general">General Policies</a></div>
|
|
|
|
|
<!--=========================================================================-->
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<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
|
|
|
|
|
order for LLVM to maintain a high standard of quality.<p>
|
2007-02-13 09:06:01 +00:00
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"> <a name="informed">Stay Informed</a> </div>
|
|
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>Developers should stay informed by reading at least the
|
2007-02-14 16:21:10 +00:00
|
|
|
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
|
|
|
|
|
email list. If you are doing anything more than just casual work on LLVM,
|
|
|
|
|
it is suggested that you also subscribe to the
|
|
|
|
|
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a>
|
|
|
|
|
list and pay attention to changes being made by others.</p>
|
2007-02-14 07:22:19 +00:00
|
|
|
<p>We recommend that active developers register an email account with
|
|
|
|
|
<a href="http://llvm.org/bugs/">LLVM Bugzilla</a> and preferably subscribe to
|
|
|
|
|
the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs">llvm-bugs</a>
|
|
|
|
|
email list to keep track of bugs and enhancements occurring in LLVM.</p>
|
2007-02-13 09:06:01 +00:00
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"> <a name="reviews">Code Reviews</a></div>
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>LLVM has a code review policy. Code review is one way to increase the
|
|
|
|
|
quality of software. We generally follow these policies:</p>
|
2007-02-13 09:06:01 +00:00
|
|
|
<ol>
|
2007-02-14 16:21:10 +00:00
|
|
|
<li>All developers are required to have significant changes reviewed
|
2007-02-13 09:06:01 +00:00
|
|
|
before they are committed to the repository.</li>
|
2007-02-19 03:50:31 +00:00
|
|
|
<li>Code reviews are conducted by email, usually on the llvm-commits
|
|
|
|
|
list.</li>
|
|
|
|
|
<li>Code can be reviewed either before it is committed or after. We expect
|
|
|
|
|
major changes to be reviewed before being committed, but smaller
|
|
|
|
|
changes (or changes where the developer owns the component) can be
|
|
|
|
|
reviewed after commit.</li>
|
2007-02-13 09:06:01 +00:00
|
|
|
<li>The developer responsible for a code change is also responsible for
|
2007-02-19 03:50:31 +00:00
|
|
|
making all necessary review-related changes.</li>
|
2007-02-13 09:06:01 +00:00
|
|
|
<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>
|
|
|
|
|
</div>
|
2007-02-19 05:47:13 +00:00
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<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>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>All feature and regression test cases must be 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>
|
|
|
|
|
<li>Test cases should be written in
|
|
|
|
|
<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>
|
|
|
|
|
<li>Test cases, especially for regressions, should be reduced as much as
|
|
|
|
|
possible, by <a href="CommandGuide/html/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>
|
|
|
|
|
</div>
|
|
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"> <a name="quality">Quality</a></div>
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>The minimum quality standards that any change must satisfy before being
|
|
|
|
|
committed to the main development branch are:</p>
|
2007-02-13 09:06:01 +00:00
|
|
|
<ol>
|
|
|
|
|
<li>Code must adhere to the
|
|
|
|
|
<a href="CodingStandards.html">LLVM Coding Standards</a>.</li>
|
|
|
|
|
<li>Code must compile cleanly (no errors, no warnings) on at least one
|
|
|
|
|
platform.</li>
|
2007-02-19 05:47:13 +00:00
|
|
|
<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>
|
2007-02-19 03:50:31 +00:00
|
|
|
<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
|
|
|
|
|
subset is "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol>
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>Additionally, the committer is responsible for addressing any problems
|
2007-02-19 05:47:13 +00:00
|
|
|
found in the future that the change is responsible for. For example:</p>
|
2007-02-19 03:50:31 +00:00
|
|
|
<ul>
|
2007-02-14 08:19:16 +00:00
|
|
|
<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 change set should not cause performance or correctness regressions
|
2007-02-13 09:06:01 +00:00
|
|
|
for the LLVM tools.</li>
|
2007-02-14 08:19:16 +00:00
|
|
|
<li>The changes should not cause performance or correctness regressions in
|
2007-02-14 16:21:10 +00:00
|
|
|
code compiled by LLVM on all applicable targets.</li>
|
2007-02-19 03:50:31 +00:00
|
|
|
<li>You are expected to address any <a href="http://llvm.org/bugs/">bugzilla
|
|
|
|
|
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
|
|
|
|
|
infrastructure normally finds these problems. A good rule of thumb is to
|
|
|
|
|
check the nightly testers for regressions the day after your change.</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
|
|
|
|
|
making progress. The developer is welcome to re-commit the change after
|
|
|
|
|
the problem has been fixed.</p>
|
2007-02-13 09:06:01 +00:00
|
|
|
</div>
|
|
|
|
|
|
2007-02-19 03:50:31 +00:00
|
|
|
<!-- _______________________________________________________________________ -->
|
2007-02-19 05:49:11 +00:00
|
|
|
<div class="doc_subsection">
|
|
|
|
|
<a name="commitaccess">Obtaining Commit Access</a></div>
|
2007-02-19 03:50:31 +00:00
|
|
|
<div class="doc_text">
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
We grant commit access to contributors with a track record of submitting high
|
|
|
|
|
quality patches. If you would like commit access, please send an email to the
|
|
|
|
|
<a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM oversight group</a>.</p>
|
|
|
|
|
|
|
|
|
|
<p>If you have recently been granted commit access, these policies apply:</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>You are granted <i>commit-after-approval</i> to all parts of LLVM.
|
|
|
|
|
To get approval, submit a <a href="#patches">patch</a> to
|
|
|
|
|
<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
|
|
|
|
|
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
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
2007-02-19 05:43:04 +00:00
|
|
|
<div class="doc_subsection"> <a name="newwork">Making a Major Change</a></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>
|
|
|
|
|
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>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
|
|
|
|
|
community before you start working on it.</p>
|
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsubsection"> <a name="incremental">Incremental Development</a>
|
2007-02-19 03:50:31 +00:00
|
|
|
</div>
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 05:43:04 +00:00
|
|
|
<p>Once the design of the new feature is finalized, the work itself should be
|
|
|
|
|
done as a series of incremental changes, not as a long-term development
|
|
|
|
|
branch. Long-term development branches have a number of drawbacks:</p>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Branches must have mainline merged into them periodically. If the branch
|
|
|
|
|
development and mainline development occur in the same pieces of code,
|
|
|
|
|
resolving merge conflicts can take a lot of time.</li>
|
|
|
|
|
<li>Other people in the community tend to ignore work on branches.</li>
|
|
|
|
|
<li>Huge changes (produced when a branch is merged back onto mainline) are
|
|
|
|
|
extremely difficult to <a href="#reviews">code review</a>.</li>
|
|
|
|
|
<li>Branches are not routinely tested by our nightly tester
|
|
|
|
|
infrastructure.</li>
|
|
|
|
|
<li>Changes developed as monolithic large changes often don't work until the
|
|
|
|
|
entire set of changes is done. Breaking it down into a set of smaller
|
|
|
|
|
changes increases the odds that any of the work will be committed to the
|
|
|
|
|
main repository.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To address these problems, LLVM uses an incremental development style and we
|
|
|
|
|
require contributors to follow this practice when making a large/invasive
|
|
|
|
|
change. Some tips:</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Large/invasive changes usually have a number of secondary changes that
|
|
|
|
|
are required before the big change can be made (e.g. API cleanup, etc).
|
|
|
|
|
These sorts of changes can often be done before the major change is done,
|
|
|
|
|
independently of that work.</li>
|
|
|
|
|
<li>The remaining inter-related work should be decomposed into unrelated
|
|
|
|
|
sets of changes if possible. Once this is done, define the first increment
|
|
|
|
|
and get consensus on what the end goal of the change is.</li>
|
|
|
|
|
<li>Increments can be stand alone (e.g. to fix a bug), or part of a planned
|
|
|
|
|
series of increments towards some development goal.</li>
|
|
|
|
|
<li>Increments should be kept as small as possible. This simplifies your
|
|
|
|
|
work (into a logical progression), simplifies code review and reduces the
|
|
|
|
|
chance that you will get negative feedback on the change. Small increments
|
|
|
|
|
also facilitate the maintenance of a high quality code base.</li>
|
|
|
|
|
<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>
|
|
|
|
|
</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
|
|
|
|
|
the change.</p>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
2007-02-19 05:43:04 +00:00
|
|
|
<div class="doc_subsection"><a name="attribution">Attribution of
|
|
|
|
|
Changes</a></div>
|
2007-02-19 03:50:31 +00:00
|
|
|
<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="#candl">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>
|
|
|
|
|
<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>
|
|
|
|
|
<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>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<!--=========================================================================-->
|
|
|
|
|
<div class="doc_section"><a name="patches">Patch Policies</a></div>
|
|
|
|
|
<!--=========================================================================-->
|
2007-02-19 03:50:31 +00:00
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>This section describes policies that apply to developers who regularly
|
|
|
|
|
contribute code to LLVM. As usual, we often accept small patches and
|
|
|
|
|
contributions that do not follow this policy. In this case, one of the
|
|
|
|
|
regular contributors has to get the code in shape.</p>
|
2007-02-13 09:06:01 +00:00
|
|
|
</div>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"> <a name="p_form">Patch Form</a></div>
|
|
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>When submitting a patch, developers must follow these rules:</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Patches must be made against the CVS HEAD (main development trunk),
|
|
|
|
|
not a branch.</li>
|
2007-02-19 03:50:31 +00:00
|
|
|
<li>Patches should be made with this command:
|
|
|
|
|
<pre>cvs diff -Ntdup -5</pre>
|
|
|
|
|
or with the utility <tt>utils/mkpatch</tt>.</li>
|
2007-02-14 07:57:48 +00:00
|
|
|
<li>Patches should not include differences in generated code such as the
|
2007-02-13 09:06:01 +00:00
|
|
|
code generated by <tt>flex</tt>, <tt>bison</tt> or <tt>tblgen</tt>. The
|
|
|
|
|
<tt>utils/mkpatch</tt> utility takes care of this for you.</li>
|
2007-02-19 03:50:31 +00:00
|
|
|
<li>Contributions must not knowingly infringe on any patents. To the best of
|
|
|
|
|
our knowledge, LLVM is free of any existing patent violations and it is our
|
|
|
|
|
intent to keep it that way.</li>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol>
|
|
|
|
|
</div>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"> <a name="p_submission">Patch Submission</a></div>
|
|
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>When a patch is ready to be submitted, these policies apply:</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Patches should be submitted immediately after they are generated. Stale
|
2007-02-14 07:57:48 +00:00
|
|
|
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 submitted by e-mail to the
|
2007-02-13 09:06:01 +00:00
|
|
|
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
|
|
|
|
|
llvm-commits</a> list.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
2007-02-14 17:20:59 +00:00
|
|
|
<div class="doc_subsection"> <a name="p_aftersub">After Submission</a></div>
|
2007-02-13 09:06:01 +00:00
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>After a patch has been submitted, these policies apply:</p>
|
|
|
|
|
<ol>
|
2007-02-14 16:21:10 +00:00
|
|
|
<li>The patch is subject to review by anyone on the
|
|
|
|
|
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a>
|
|
|
|
|
email list.</li>
|
2007-02-14 07:57:48 +00:00
|
|
|
<li>Changes recommended by a reviewer should be incorporated into your
|
2007-02-14 16:21:10 +00:00
|
|
|
patch or you should explain why the reviewer is incorrect.
|
|
|
|
|
<li>Changes to the patch must be re-submitted to the
|
|
|
|
|
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a>
|
|
|
|
|
email list.</li>
|
|
|
|
|
<li>This process iterates until all review issues have been addressed.</li>
|
2007-02-13 09:06:01 +00:00
|
|
|
</ol>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
2007-02-14 17:20:59 +00:00
|
|
|
<div class="doc_subsection"> <a name="p_aftercommit">After Commit</a></div>
|
2007-02-13 09:06:01 +00:00
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>After a patch has been committed, these policies apply:</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>The patch is subject to further review by anyone on the llvm-commits
|
|
|
|
|
email list.</li>
|
|
|
|
|
<li>The patch submitter is responsible for all aspects of the patch per
|
|
|
|
|
the <a href="quality">quality policy</a> above.</li>
|
|
|
|
|
<li>If the patch is discovered to not meet the
|
2007-02-14 16:21:10 +00:00
|
|
|
<a href="quality">quality policy</a> standards within a reasonable time
|
2007-02-13 09:06:01 +00:00
|
|
|
frame (24 hours), it may be subject to reversal.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
</div>
|
|
|
|
|
|
2007-02-14 07:22:19 +00:00
|
|
|
<!--=========================================================================-->
|
|
|
|
|
<div class="doc_section"><a name="candl">Copyright and License</a></div>
|
|
|
|
|
<!--=========================================================================-->
|
2007-02-19 03:50:31 +00:00
|
|
|
|
2007-02-14 07:22:19 +00:00
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>We address here the issues of copyright and license for the LLVM project.
|
2007-02-14 16:21:10 +00:00
|
|
|
The object of the copyright and license is the LLVM source code and
|
|
|
|
|
documentation.
|
2007-02-14 07:22:19 +00:00
|
|
|
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>.
|
|
|
|
|
|
|
|
|
|
<div class="doc_notes">
|
2007-02-19 03:50:31 +00:00
|
|
|
<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
|
|
|
|
|
attorney.</b></p>
|
2007-02-14 07:22:19 +00:00
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"><a name="copyright">Copyright</a></div>
|
|
|
|
|
<div class="doc_text">
|
|
|
|
|
<p>
|
2007-02-14 16:21:10 +00:00
|
|
|
<p>For consistency and ease of management, the project requires the
|
2007-02-19 03:50:31 +00:00
|
|
|
copyright for all LLVM software to be held by a single copyright holder:
|
|
|
|
|
the University of Illinois (UIUC).</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Although UIUC may eventually reassign the copyright of the software to another
|
|
|
|
|
entity (e.g. a dedicated non-profit "LLVM Organization", or something)
|
|
|
|
|
the intent for the project is to always have a single entity hold the
|
|
|
|
|
copyrights to LLVM at any given time.</p>
|
|
|
|
|
|
|
|
|
|
<p>We believe that having a single copyright
|
2007-02-14 07:22:19 +00:00
|
|
|
holder is in the best interests of all developers and users as it greatly
|
|
|
|
|
reduces the managerial burden for any kind of administrative or technical
|
2007-02-19 03:50:31 +00:00
|
|
|
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>
|
2007-02-14 07:22:19 +00:00
|
|
|
</div>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
2007-02-14 07:22:19 +00:00
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"><a name="license">License</a></div>
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>We intend to keep LLVM perpetually open source
|
|
|
|
|
and to use a liberal open source license. The current license is the
|
2007-02-14 16:21:10 +00:00
|
|
|
<a href="http://www.opensource.org/licenses/UoI-NCSA.php">
|
|
|
|
|
University of Illinois/NCSA Open Source License</a>, which boils
|
2007-02-14 07:22:19 +00:00
|
|
|
down to this:</p>
|
|
|
|
|
<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>You can't use our names to promote your LLVM derived products.</li>
|
|
|
|
|
<li>There's no warranty on LLVM at all.</li>
|
|
|
|
|
</ul>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
|
|
|
|
<p>We believe this fosters the widest adoption of LLVM because it <b>allows
|
|
|
|
|
commercial products to be derived from LLVM</b> with few restrictions and
|
2007-02-14 22:55:40 +00:00
|
|
|
without a requirement for making any derived works also open source (i.e.
|
2007-02-19 03:50:31 +00:00
|
|
|
LLVM's license is not a "copyleft" license like the GPL). We suggest that you
|
|
|
|
|
read the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">License</a>
|
2007-02-14 22:58:39 +00:00
|
|
|
if further clarification is needed.</p>
|
2007-02-19 03:50:31 +00:00
|
|
|
|
|
|
|
|
<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
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
<p>We have no plans to change the license of LLVM. If you have questions
|
|
|
|
|
or comments about the license, please contact the <a
|
|
|
|
|
href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a>.</p>
|
|
|
|
|
|
2007-02-14 07:22:19 +00:00
|
|
|
</div>
|
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
|
<div class="doc_subsection"><a name="devagree">Developer Agreements</a></div>
|
|
|
|
|
<div class="doc_text">
|
2007-02-19 03:50:31 +00:00
|
|
|
<p>With regards to the LLVM copyright and licensing, developers agree to
|
|
|
|
|
assign their copyrights to UIUC for any contribution made so that
|
|
|
|
|
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
|
2007-02-19 05:49:11 +00:00
|
|
|
project uses.</p>
|
2007-02-14 07:22:19 +00:00
|
|
|
</div>
|
|
|
|
|
|
2007-02-13 09:06:01 +00:00
|
|
|
<!-- *********************************************************************** -->
|
|
|
|
|
<hr>
|
|
|
|
|
<address>
|
|
|
|
|
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
|
|
|
|
|
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>
|
2007-02-19 03:50:31 +00:00
|
|
|
Written by: the
|
2007-02-14 07:57:48 +00:00
|
|
|
<a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a><br>
|
2007-02-13 09:06:01 +00:00
|
|
|
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
|
|
|
|
|
Last modified: $Date$
|
|
|
|
|
</address>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
