diff options
| author | Chris Lattner <sabre@nondot.org> | 2007-02-19 03:50:31 +0000 |
|---|---|---|
| committer | Chris Lattner <sabre@nondot.org> | 2007-02-19 03:50:31 +0000 |
| commit | 450f40af1f2a0ffa785ce1ea5397b225f0370a8d (patch) | |
| tree | bbd6ff6a34e6a92bf0be56bfea236ba8f783ee73 /docs | |
| parent | 4f28a2f88fdc3fe53a31927069d6f8f488f74505 (diff) | |
| download | llvm-450f40af1f2a0ffa785ce1ea5397b225f0370a8d.tar.gz llvm-450f40af1f2a0ffa785ce1ea5397b225f0370a8d.tar.bz2 llvm-450f40af1f2a0ffa785ce1ea5397b225f0370a8d.tar.xz | |
A bunch of editting. I'm still not done with the 'patches' section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34401 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/DeveloperPolicy.html | 424 |
1 files changed, 223 insertions, 201 deletions
diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 27d2e81304..b7548c9586 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -6,44 +6,37 @@ <link rel="stylesheet" href="llvm.css" type="text/css"> </head> <body> - <div class="doc_warning">DRAFT Only. DRAFT Only. DRAFT Only. DRAFT Only.</div> <div class="doc_title">LLVM Developer Policy</div> -<table class="layout"><tr class="layout"><td class="layout"> -<h2>Contents</h2> <ol> <li><a href="#introduction">Introduction</a></li> <li><a href="#general">General Policies</a> <ol> <li><a href="#informed">Stay Informed</a> </li> - <li><a href="#newwork">Starting New Work</a></li> + <li><a href="#newwork">Starting New Work</a></li> <li><a href="#reviews">Code Reviews</a></li> - <li><a href="#incremental">Incremental Development</a></li> <li><a href="#quality">Quality</a></li> <li><a href="#testcases">Test Cases</a></li> + <li><a href="#c_new">Obtaining Commit Access</a></li> + <li><a href="#incremental">Incremental Development</a></li> + <li><a href="#attribution">Attribution</a></li> </ol></li> <li><a href="#patches">Patch Policies</a> <ol> <li><a href="#p_form">Patch Form</a></li> - <li><a href="#p_testing">Patch Testing</a></li> <li><a href="#p_submission">Patch Submission</a></li> <li><a href="#p_aftersub">After Submission</a></li> <li><a href="#p_aftercommit">After Commit</a></li> - <li><a href="#c_access">Obtaining Commit Access</a></li> - <li><a href="#c_new">New Committers</a></li> </ol></li> <li><a href="#candl">Copyright and License</a> <ol> - <li><a href="#attribution">Attribution</a></li> <li><a href="#copyright">Copyright</a></li> <li><a href="#license">License</a></li> <li><a href="#devagree">Developer Agreements</a></li> </ol></li> <li><a href="#terms">Terminology</a></li> - <li><a href="#polnotes">Policy Notes</a></li> </ol> <div class="doc_author">Written by LLVM Oversight Team</div> -</td><td class="layout"> <!--=========================================================================--> <div class="doc_section"><a name="introduction">Introduction</a></div> @@ -59,8 +52,7 @@ <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>Indicate that LLVM is a mature project with a thriving community and - sensible policies directing its ongoing development.</li> + <li>Keep the top of tree CVS/SVN trees as stable as possible.</li> </ol> </div> @@ -68,9 +60,12 @@ <div class="doc_section"><a name="general">General Policies</a></div> <!--=========================================================================--> <div class="doc_text"> - <p>This section contains policies that pertain generally to LLVM developers. - LLVM Developers are expected to meet the following obligations in order - for LLVM to maintain a high standard of quality.<p> + <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> </div> <!-- _______________________________________________________________________ --> @@ -95,78 +90,61 @@ 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: - <ul> + <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> - </ul> + </ol> <p>The design of LLVM is carefully controlled to ensure that all the pieces - fit together well. If you plan to make a major change to the way LLVM works or + 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> -</td></tr></table> <!-- _______________________________________________________________________ --> <div class="doc_subsection"> <a name="reviews">Code Reviews</a></div> <div class="doc_text"> - <p>LLVM has a code review policy. Code review is an excellent way to ensure - high quality in the software. The following policies apply:</p> + <p>LLVM has a code review policy. Code review is one way to increase the + quality of software. We generally follow these policies:</p> <ol> <li>All developers are required to have significant changes reviewed before they are committed to the repository.</li> - <li>Code reviews are conducted by email.</li> - <li>Code can be reviewed either before it is committed or after.</li> + <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> <li>The developer responsible for a code change is also responsible for - making all necessary review changes.</li> + making all necessary review-related changes.</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> </div> - -<!-- _______________________________________________________________________ --> -<div class="doc_subsection"> <a name="incremental">Incremental Development</a> -</div> -<div class="doc_text"> - <p>LLVM uses an incremental development style and all developers are expected - to follow this practice. Incremental development is a big key to LLVM's - success and it is essential that developers submit incremental patches. The - following defines the incremental development approach:</p> - <ol> - <li>The first task is to define the increment and get consensus (with the - LLVM development community) on what the end goal of the change is. Making - random small changes that go nowhere is not useful for anyone.</li> - <li>An increment is the smallest patch size necessary to effect one change - in LLVM.</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>Larger increments require a larger testing effort.</li> - </ol> -</div> - <!-- _______________________________________________________________________ --> <div class="doc_subsection"> <a name="quality">Quality</a></div> <div class="doc_text"> - <p>The minimum quality standards for any change to the main development - branch are:</p> + <p>The minimum quality standards that any change must satisfy before being + committed to the main development branch are:</p> <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> <li>Code must pass the deja gnu (llvm/test) 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 + subset is "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li> </ol> - <p>Additionally, the committer is responsible for addressing all of the - following items (preferably before submission):</p> - <ol> + <p>Additionally, the committer is responsible for addressing any problems + found 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 @@ -175,15 +153,26 @@ for the LLVM tools.</li> <li>The changes should not cause performance or correctness regressions in code compiled by LLVM on all applicable targets.</li> - </ol> + <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> </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 regressions and new - features and include them with their changes. The following policies - apply:</p> + <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 @@ -192,7 +181,7 @@ <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 lvm-gcc C++ + 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 @@ -201,17 +190,136 @@ 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> + coverage: not features or regressions.</li> </ol> </div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsection"> <a name="c_new">Obtaining Commit Access</a></div> +<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> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsection"> <a name="incremental">Incremental Development</a> +</div> +<div class="doc_text"> + <p>When making a large change to LLVM, we use a incremental style of + development instead of having long-term development branches. Long-term + development branches have a number of drawbacks:</p> + + <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> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsection"><a name="attribution">Attribution</a></div> +<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> + + <!--=========================================================================--> <div class="doc_section"><a name="patches">Patch Policies</a></div> <!--=========================================================================--> + <div class="doc_text"> - <p>This section contains policies that pertain to submitting patches - to LLVM and committing code to the repository</p> + <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> </div> + <!-- _______________________________________________________________________ --> <div class="doc_subsection"> <a name="p_form">Patch Form</a></div> <div class="doc_text"> @@ -219,31 +327,18 @@ <ol> <li>Patches must be made against the CVS HEAD (main development trunk), not a branch.</li> - <li>Patches should be made with this command:<pre> - cvs diff -Ntdup -5</pre> or with the utility <tt>utils/mkpatch</tt>.</li> + <li>Patches should be made with this command: + <pre>cvs diff -Ntdup -5</pre> + or with the utility <tt>utils/mkpatch</tt>.</li> <li>Patches should not include differences in generated code such as the 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> - <li>Patches must not include any patent violations. 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> - </ol> -</div> -<!-- _______________________________________________________________________ --> -<div class="doc_subsection"> <a name="p_testing">Patch Testing</a></div> -<div class="doc_text"> - <p>Before a patch is submitted for review, it should be tested to ensure - that:</p> - <ol> - <li>The patch must compile against the CVS HEAD cleanly (zero warnings, zero - errors).</li> - <li>All the llvm/test (Deja Gnu) tests must pass.</li> - <li>The patch should cause no regressions in the llvm-test test suite. How - much testing is appropriate depends on the nature of the patch. We leave it - to your good judgement, but you will be responsible for fixing any - regressions or reverting the patch.</li> + <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> </ol> </div> + <!-- _______________________________________________________________________ --> <div class="doc_subsection"> <a name="p_submission">Patch Submission</a></div> <div class="doc_text"> @@ -290,55 +385,10 @@ </ol> </div> -<!-- _______________________________________________________________________ --> -<div class="doc_subsection"> <a name="c_access">Obtaining Commit Access</a></div> -<div class="doc_text"> - <p>Commit access to the repository is granted according to this policy:</p> - <ol> - <li>Commit access is not granted to anyone unless they specifically ask for - it.</li> - <li>Requests for commit access must be sent to the - <a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a>.</li> - <li>Granting commit access is at the sole discretion of the LLVM Oversight - Group.</li> - </ol> - <p>Submitting patches to LLVM via the patch policy above will greatly - increase the chance that your request for commit access is granted. Getting - to know the members of the LLVM community (email, IRC, in person contact, - etc.) will also increase your chances.</p> -</div> - -<!-- _______________________________________________________________________ --> -<div class="doc_subsection"> <a name="c_new">New Committers</a></div> -<div class="doc_text"> - <p>For those who have recently obtained commit access, the following policies - apply:</p> - <ol> - <li>You are granted <i>commit-after-approval</i> to all parts of LLVM. - To get approval, submit a patch to - <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a> - per the <a href="#patches">patch policies</a> above. 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.</li> - <li>You are allowed to commit patches without approval to those portions - of LLVM that you own (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>Commits that violate the <a href="quality">quality standards</a> 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.</li> - <li>Multiple violations of these policies or a single egregious violation - may cause commit access to be revoked.</li> - </ol> -</div> - <!--=========================================================================--> <div class="doc_section"><a name="candl">Copyright and License</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 @@ -347,36 +397,13 @@ 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> <div class="doc_notes"> - <p>NOTE: This section deals with legal matters but does not provide legal - advice. It is intended only as a general guideline.</p> + <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> </div> -<!-- _______________________________________________________________________ --> -<div class="doc_subsection"><a name="attribution">Attribution</a></div> -<div class="doc_text"> - <p>The LLVM project believes in correct attribution of contributions to - their contributors, as follows:</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">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 copyright but does - correctly attribute the file to its 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.</li> - <li>Developers should submit or commit patches to the - <a href="http://llvm.org/cvsweb/cvsweb.cgi/llvm/CREDITS.TXT?rev=1.67&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> <!-- _______________________________________________________________________ --> @@ -384,24 +411,27 @@ <div class="doc_text"> <p> <p>For consistency and ease of management, the project requires the - copyright for all LLVM software to be held by a single copyright holder. - Although UIUC may assign the copyright of the software to another entity, - the intent for the project is to always have a single entity hold the copy - rights to LLVM at any given time. - <p>Having multiple copyright holders for various portions of LLVM is - problematic in the management of the software. Having a single copyright + 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 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 - decisions about LLVM.</p> + 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> + <!-- _______________________________________________________________________ --> <div class="doc_subsection"><a name="license">License</a></div> <div class="doc_text"> - <p>LLVM licensing decisions will be made by the LLVM Oversight Group. Any - issues, comments or suggestions with the licensing should be sent to the - <a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a>.</p> - <p>The LLVM Oversight Group intends to keep LLVM perpetually open source - and to use liberal open source licenses. The current license is the + <p>We intend to keep LLVM perpetually open source + and to use a liberal open source license. The current license is the <a href="http://www.opensource.org/licenses/UoI-NCSA.php"> University of Illinois/NCSA Open Source License</a>, which boils down to this:</p> @@ -412,22 +442,37 @@ <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> - <p>We believe this fosters the widest adoption of LLVM because it allows - commercial products to be derived from LLVM with few restrictions and + + <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 without a requirement for making any derived works also open source (i.e. - LLVM's license is not a <i>copyleft</i> license). We suggest that you read - the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">License</a> + 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> 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 + 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> + </div> <!-- _______________________________________________________________________ --> <div class="doc_subsection"><a name="devagree">Developer Agreements</a></div> <div class="doc_text"> - <p>With regards to the LLVM copyright and licensing, developers agree to:</p> - <ul> - <li>assign their copy rights to UIUC for any contribution made so that - the entire software base can be managed by a single copyright holder.</li> - <li>allow their contribution(s) to be licensed as open source by the then - current license chosen by the LLVM Oversight Group.</li> + <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 + project uses.</li> </ul> </div> @@ -445,10 +490,6 @@ <dt><a name="t_commit">Commit</a><dt> <dd>A <a href="t_change">change</a> submitted directly to LLVM software repository via the <tt>cvs commit</tt> command.</dd> - <dt><a name="t_copleft">Copyleft</a></dt> - <dd>A licensing policy that requires the licensee to adopt the terms of the - license for <i>derived</i> works. LLVM does not subscribe to this - policy.</dd> <dt><a name="t_developer">Developer</a></dt> <dd>Anyone who submits a <a href="#t_change">change</a> to LLVM.</dd> <dt><a name="t_inrement">Increment</a></dt> @@ -456,31 +497,12 @@ <a href="#t_patch">patch</a> or <a href="#t_commit">commit</a>, that are related by a single common purpose. Increments are atomic as they leave LLVM in a stable state (both compiling and working properly).</dd> - <dt><a name="t_must">Must</a></dt> - <dd>When used in a policy statement, the term <i>must</i> implies a - non-optional requirement on the developer.</dd> <dt><a name="t_patch">Patch</a></dt> <dd>A <a href="#t_change">change</a> submitted by email in patch (diff) format generated by the <tt>cvs diff</tt> command.</dd> - <dt><a name="t_should">Should</a></dt> - <dd>When used in a policy statement, the term <i>should</i> implies a - recommended but optional requirement on the developer.</dd> </dl> </div> -<!--=========================================================================--> -<div class="doc_section"><a name="polnotes">Policy Notes</a></div> -<!--=========================================================================--> -<div class="doc_text"> - <p>This section contains some notes on policy topics that need to be - resolved and incorporated into the main body of the document above.</p> - <ol> - <li>When to open a new bug and when to re-use an existing one. For example - PR1158. If the same assertion happens do you open a new bug or reopen - 1158?</li> - </ol> -</div> - <!-- *********************************************************************** --> <hr> <address> @@ -488,7 +510,7 @@ 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$ |