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
This commit is contained in:
Chris Lattner 2007-02-19 05:57:29 +00:00
parent 1acdc957d2
commit 1653fec412

View File

@ -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>
@ -91,6 +92,37 @@
email list to keep track of bugs and enhancements occurring in LLVM.</p>
</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">
@ -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>