<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>
+ <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 Subversion trunk, not a branch, and not an
old version of LLVM. This makes it easy to apply the patch.</li>
the time the patch was created and the time it is applied.</li>
<li>Patches should be made with this command:
- <pre>svn diff -x -u</pre>
- or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read the
- diff.</li>
+ <div class="doc_code"><pre>svn diff -x -u</pre></div>
+ or with the utility <tt>utils/mkpatch</tt>, which makes 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
+ code generated by <tt>autoconf</tt> or <tt>tblgen</tt>. The
<tt>utils/mkpatch</tt> utility takes care of this for you.</li>
-
</ol>
<p>When sending a patch to a mailing list, it is a good idea to send it as an
<tt>Content-Disposition: inline</tt> rather than <tt>Content-Disposition:
attachment</tt>. Apple Mail gamely displays such a file inline, making it
difficult to work with for reviewers using that program.</p>
-</p>
</div>
<!-- _______________________________________________________________________ -->
Illinois/NCSA Open Source License</a>.</p>
<div class="doc_notes">
- <p><b>NOTE: This section deals with legal matters but does not provide
- legal advice. We are not lawyers, please seek legal counsel from an
- attorney.</b></p>
+ <p style="text-align:center;font-weight:bold">NOTE: This section
+ deals with legal matters but does not provide legal advice. We are not
+ lawyers, please seek legal counsel from an attorney.</p>
</div>
</div>