[llvm-commits] CVS: llvm/docs/DeveloperPolicy.html
Chris Lattner
sabre at nondot.org
Sun Feb 18 21:57:46 PST 2007
Changes in directory llvm/docs:
DeveloperPolicy.html updated: 1.23 -> 1.24
---
Log message:
refactor the top-level 'patches' section into a subsection of General Policies.
Much of its content is now in other parts of the doc, and this brings it up
immediately after 'stay informed' and right before 'code reviews'.
---
Diffs of the changes: (+37 -78)
DeveloperPolicy.html | 115 ++++++++++++++++-----------------------------------
1 files changed, 37 insertions(+), 78 deletions(-)
Index: llvm/docs/DeveloperPolicy.html
diff -u llvm/docs/DeveloperPolicy.html:1.23 llvm/docs/DeveloperPolicy.html:1.24
--- llvm/docs/DeveloperPolicy.html:1.23 Sun Feb 18 23:49:11 2007
+++ llvm/docs/DeveloperPolicy.html Sun Feb 18 23:57:29 2007
@@ -12,7 +12,8 @@
<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="#informed">Stay Informed</a></li>
+ <li><a href="#patches">Making a Patch</a></li>
<li><a href="#reviews">Code Reviews</a></li>
<li><a href="#testcases">Test Cases</a></li>
<li><a href="#quality">Quality</a></li>
@@ -92,6 +93,37 @@
</div>
<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"> <a name="patches">Making a Patch</a></div>
+
+<div class="doc_text">
+
+<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>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>
+ or with the utility <tt>utils/mkpatch</tt>. to make it easy to read the
+ diff.</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>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="reviews">Code Reviews</a></div>
<div class="doc_text">
<p>LLVM has a code review policy. Code review is one way to increase the
@@ -106,7 +138,9 @@
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-related changes.</li>
+ making all necessary review-related changes.</li>
+ <li>Code review can be an iterative process, which goes until all the patch
+ is ready to be committed.</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
@@ -325,81 +359,6 @@
</div>
-<!--=========================================================================-->
-<div class="doc_section"><a name="patches">Patch Policies</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
- <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">
- <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>
- <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>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">
- <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
- 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
- <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
- llvm-commits</a> list.</li>
- </ol>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"> <a name="p_aftersub">After Submission</a></div>
-<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
- <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.
- <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>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"> <a name="p_aftercommit">After Commit</a></div>
-<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
- <a href="quality">quality policy</a> standards within a reasonable time
- frame (24 hours), it may be subject to reversal.</li>
- </ol>
-</div>
<!--=========================================================================-->
<div class="doc_section"><a name="candl">Copyright and License</a></div>
@@ -501,7 +460,7 @@
Written by: the
<a href="mailto:llvm-oversight at cs.uiuc.edu">LLVM Oversight Group</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2007/02/19 05:49:11 $
+ Last modified: $Date: 2007/02/19 05:57:29 $
</address>
</body>
</html>
More information about the llvm-commits
mailing list