summaryrefslogtreecommitdiff
path: root/docs/DeveloperPolicy.html
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2007-02-19 05:57:29 +0000
committerChris Lattner <sabre@nondot.org>2007-02-19 05:57:29 +0000
commit1653fec412e8c365645262b41f27becc7aca1e29 (patch)
treef3a3da8165d49d401b8c98da721dc0749ca70bb4 /docs/DeveloperPolicy.html
parent1acdc957d238c64366f6dc87188cb2dad68ae9d7 (diff)
downloadllvm-1653fec412e8c365645262b41f27becc7aca1e29.tar.gz
llvm-1653fec412e8c365645262b41f27becc7aca1e29.tar.bz2
llvm-1653fec412e8c365645262b41f27becc7aca1e29.tar.xz
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'. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34406 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/DeveloperPolicy.html')
-rw-r--r--docs/DeveloperPolicy.html113
1 files changed, 36 insertions, 77 deletions
diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html
index 56f5b88edb..1bf62f17aa 100644
--- a/docs/DeveloperPolicy.html
+++ b/docs/DeveloperPolicy.html
@@ -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 @@ Changes</a></div>
</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>