remove terminology section (this is not a legal document)

move testcases above quality.  Mention that a testcase is part of quality.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34404 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html
index c3d364c..21848a8 100644 (file)
--- a/docs/DeveloperPolicy.html
+++ b/docs/DeveloperPolicy.html
@@ -36,7 +36,6 @@
     <li><a href="#license">License</a></li>
     <li><a href="#devagree">Developer Agreements</a></li>
   </ol></li>
-  <li><a href="#terms">Terminology</a></li>
 </ol>
 <div class="doc_author">Written by LLVM Oversight Team</div>
 
@@ -114,6 +113,33 @@
     else.</li>
   </ol>
 </div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
+<div class="doc_text">
+  <p>Developers are required to create test cases for any bugs fixed and any new
+  features added. The following policies apply:</p>
+  <ol>
+    <li>All feature and regression test cases must be added to the 
+    <tt>llvm/test</tt> directory. The appropriate sub-directory should be 
+    selected (see the <a href="TestingGuide.html">Testing Guide</a> for 
+    details).</li>
+    <li>Test cases should be written in 
+    <a href="LangRef.html">LLVM assembly language</a> unless the
+    feature or regression being tested requires another language (e.g. the
+    bug being fixed or feature being implemented is in the llvm-gcc C++
+    front-end).</li>
+    <li>Test cases, especially for regressions, should be reduced as much as 
+    possible, by <a href="CommandGuide/html/bugpoint.html">bugpoint</a> or
+    manually. It is unacceptable 
+    to place an entire failing program into <tt>llvm/test</tt> as this creates
+    a <i>time-to-test</i> burden on all developers. Please keep them short.</li>
+    <li>More extensive test cases (applications, benchmarks, etc.) should be 
+    added to the <tt>llvm-test</tt> test suite.  This test suite is for 
+    coverage: not features or regressions.</li>
+  </ol>
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"> <a name="quality">Quality</a></div>
 <div class="doc_text">
@@ -124,14 +150,17 @@
     <a href="CodingStandards.html">LLVM Coding Standards</a>.</li>
     <li>Code must compile cleanly (no errors, no warnings) on at least one 
     platform.</li>
-    <li>Code must pass the deja gnu (llvm/test) test suite.</li>
+    <li>Bug fixes and new features should <a href="#testcases">include a
+        testcase</a> so we know if the fix/feature ever regresses in the
+        future.</li>
+    <li>Code must pass the dejagnu (llvm/test) test suite.</li>
     <li>The code must not cause regressions on a reasonable subset of llvm-test,
         where "reasonable" depends on the contributor's judgement and the scope
         of the change (more invasive changes require more testing). A reasonable
         subset is "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li>
   </ol>
   <p>Additionally, the committer is responsible for addressing any problems
-  found that the change is responsible for.  For example:</p>
+  found in the future that the change is responsible for.  For example:</p>
   <ul>
     <li>The code should compile cleanly on all platforms.</li>
     <li>The changes should not cause regressions in the <tt>llvm-test</tt>
@@ -157,32 +186,6 @@
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
-<div class="doc_text">
-  <p>Developers are required to create test cases for any bugs fixed and any new
-  features added. The following policies apply:</p>
-  <ol>
-    <li>All feature and regression test cases must be added to the 
-    <tt>llvm/test</tt> directory. The appropriate sub-directory should be 
-    selected (see the <a href="TestingGuide.html">Testing Guide</a> for 
-    details).</li>
-    <li>Test cases should be written in 
-    <a href="LangRef.html">LLVM assembly language</a> unless the
-    feature or regression being tested requires another language (e.g. the
-    bug being fixed or feature being implemented is in the llvm-gcc C++
-    front-end).</li>
-    <li>Test cases, especially for regressions, should be reduced as much as 
-    possible, by <a href="CommandGuide/html/bugpoint.html">bugpoint</a> or
-    manually. It is unacceptable 
-    to place an entire failing program into <tt>llvm/test</tt> as this creates
-    a <i>time-to-test</i> burden on all developers. Please keep them short.</li>
-    <li>More extensive test cases (applications, benchmarks, etc.) should be 
-    added to the <tt>llvm-test</tt> test suite.  This test suite is for 
-    coverage: not features or regressions.</li>
-  </ol>
-</div>
-
-<!-- _______________________________________________________________________ -->
 <div class="doc_subsection"> <a name="c_new">Obtaining Commit Access</a></div>
 <div class="doc_text">
 
@@ -488,33 +491,6 @@ Changes</a></div>
   </ul>
 </div>
 
-<!--=========================================================================-->
-<div class="doc_section"><a name="terms">Terminology</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-  <p>So that the policies defined in this document are clear, we define some 
-  terms here.</p>
-  <dl>
-    <dt><a name="t_change">Change</a></dt>
-    <dd>Any modification to LLVM including documentation, tests, build system,
-    etc. either in <a href="#t_patch">patch</a> or 
-    <a href="#t_commit">commit</a> form.</dd>
-    <dt><a name="t_commit">Commit</a><dt>
-    <dd>A <a href="t_change">change</a> submitted directly to LLVM software
-    repository via the <tt>cvs commit</tt> command.</dd>
-    <dt><a name="t_developer">Developer</a></dt>
-    <dd>Anyone who submits a <a href="#t_change">change</a> to LLVM.</dd>
-    <dt><a name="t_inrement">Increment</a></dt>
-    <dd>A <a href="#t_change">change</a> or set of changes, whether by
-    <a href="#t_patch">patch</a> or <a href="#t_commit">commit</a>, that are 
-    related by a single common purpose. Increments are atomic as they 
-    leave LLVM in a stable state (both compiling and working properly).</dd> 
-    <dt><a name="t_patch">Patch</a></dt>
-    <dd>A <a href="#t_change">change</a> submitted by email in patch (diff) 
-    format generated by the <tt>cvs diff</tt> command.</dd>
-  </dl>
-</div>
-
 <!-- *********************************************************************** -->
 <hr>
 <address>