diff options
Diffstat (limited to 'docs/DeveloperPolicy.html')
| -rw-r--r-- | docs/DeveloperPolicy.html | 113 |
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> |