Changes in directory llvm/docs:
DeveloperPolicy.html updated: 1.12 -> 1.13 --- Log message: A few changes: 1. Fix typos 2. Move Terminology to the end 3. Simplify language in a few spots. 4. Add a policy that larger increments require a larger testing effort. --- Diffs of the changes: (+78 -70) DeveloperPolicy.html | 148 ++++++++++++++++++++++++++------------------------- 1 files changed, 78 insertions(+), 70 deletions(-) Index: llvm/docs/DeveloperPolicy.html diff -u llvm/docs/DeveloperPolicy.html:1.12 llvm/docs/DeveloperPolicy.html:1.13 --- llvm/docs/DeveloperPolicy.html:1.12 Wed Feb 14 02:23:08 2007 +++ llvm/docs/DeveloperPolicy.html Wed Feb 14 10:21:10 2007 @@ -54,47 +54,13 @@ the policy in clear terms, we hope each developer can know ahead of time what to expect when making LLVM contributions.</p> </div> -<!--=========================================================================--> -<div class="doc_section"><a name="terms">Terminology</a></div> -<!--=========================================================================--> -<div class="doc_text"> - <p>So that the policies defined in the next sections are clear, we first - define some terms here.</p> - <dl> - <dt><a name="t_change">Change</a></dt> - <dd>Any modification to LLVM including documentation, tests, build system, - etc. either in <a href="#t_patch">patch</a> or - <a href="#t_commit">commit</a> form.</dd> - <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_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> - <dd>A <a href="#t_change">change</a> or set of changes, whether by - <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> - -</td></tr></table> <!--=========================================================================--> <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. - <p>LLVM Developers are expected to meet the following obligations in order + LLVM Developers are expected to meet the following obligations in order for LLVM to maintain a high standard of quality.<p> </div> @@ -102,10 +68,11 @@ <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 - <a href="mailto:[EMAIL PROTECTED]">llvmdev</a> email list. If you are doing - anything more than just casual work on LLVM, it is highly suggested that you - also subscribe to the llvm-commits list and pay attention to changes being - made by others.</p> + <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> <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> @@ -123,14 +90,15 @@ <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 issues around the proposed work are discussed and - resolved before any significant work is accomplished.</li> + <li>ensure that any technical issues around the proposed work are + discussed and resolved before any significant work is done.</li> </ul> <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 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> @@ -138,7 +106,7 @@ <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> <ol> - <li>All developers are required to have any significant changes reviewed + <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> @@ -171,6 +139,7 @@ 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> @@ -196,7 +165,7 @@ <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 - code compiled with LLVM on all applicable targets.</li> + code compiled by LLVM on all applicable targets.</li> </ol> </div> @@ -211,15 +180,16 @@ <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 LLVM assembly language unless the + <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++ front-end).</li> - <li>Test cases, especially for regressions, should be much as reduced as + <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. Keep them short!</li> + 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> @@ -256,7 +226,10 @@ <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>All the llvm-test tests must pass on at least one platform.</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> </ol> </div> <!-- _______________________________________________________________________ --> @@ -278,15 +251,15 @@ <div class="doc_text"> <p>After a patch has been submitted, these policies apply:</p> <ol> - <li>The patch is subject to review by anyone on the llvm-commits email list. - </li> + <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> <li>Changes recommended by a reviewer should be incorporated into your - patch or you should explain why the reviewer is incorrect. This process - iterates until there are no more review comments.</li> - <li>If the submitter believes the review comment is in error, a response to - the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits";> - llvm-commits</a> list should be made explaining why the recommendation - cannot be followed.</li> + 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> </ol> </div> @@ -300,7 +273,7 @@ <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 - <a href="quality">quality standards</a> standards within a reasonable time + <a href="quality">quality policy</a> standards within a reasonable time frame (24 hours), it may be subject to reversal.</li> </ol> </div> @@ -333,19 +306,19 @@ <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 patch policies above. When approved you may commit it - yourself.</li> + 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 granted <i>commit-without-approval</i> 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>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 developers is welcome to re-commit the change after + 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> @@ -357,7 +330,8 @@ <!--=========================================================================--> <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 and documentation. + The object of the copyright and license is the LLVM source code and + documentation. 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 @@ -366,7 +340,7 @@ <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> + advice. It is intended only as a general guideline only.</p> </div> <!-- _______________________________________________________________________ --> @@ -388,7 +362,7 @@ <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 s + <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> @@ -398,7 +372,7 @@ <div class="doc_subsection"><a name="copyright">Copyright</a></div> <div class="doc_text"> <p> - <p>However, for consistency and ease of management, the project requires the + <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 @@ -417,7 +391,8 @@ <a href="mailto:[EMAIL PROTECTED]">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 - University of Illinois Open Source License (see LICENSE.TXT), which boils + <a href="http://www.opensource.org/licenses/UoI-NCSA.php";> + University of Illinois/NCSA Open Source License</a>, which boils down to this:</p> <ul> <li>You can freely distribute LLVM.</li> @@ -446,6 +421,39 @@ </div> <!--=========================================================================--> +<div class="doc_section"><a name="terms">Terminology</a></div> +<!--=========================================================================--> +<div class="doc_text"> + <p>So that the policies defined in this document are clear, we define some + terms here.</p> + <dl> + <dt><a name="t_change">Change</a></dt> + <dd>Any modification to LLVM including documentation, tests, build system, + etc. either in <a href="#t_patch">patch</a> or + <a href="#t_commit">commit</a> form.</dd> + <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_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> + <dd>A <a href="#t_change">change</a> or set of changes, whether by + <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="notes">Policy Notes</a></div> <!--=========================================================================--> <div class="doc_text"> @@ -468,7 +476,7 @@ Written By: the <a href="mailto:[EMAIL PROTECTED]">LLVM Oversight Group</a><br> <a href="http://llvm.org";>The LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2007/02/14 08:23:08 $ + Last modified: $Date: 2007/02/14 16:21:10 $ </address> </body> </html> _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
