[llvm-commits] CVS: llvm/docs/DeveloperPolicy.html

Chris Lattner sabre at nondot.org
Sun Feb 18 21:59:47 PST 2007



Changes in directory llvm/docs:

DeveloperPolicy.html updated: 1.24 -> 1.25
---
Log message:

fix TOC, clarify bullet in incremental dev


---
Diffs of the changes:  (+7 -11)

 DeveloperPolicy.html |   18 +++++++-----------
 1 files changed, 7 insertions(+), 11 deletions(-)


Index: llvm/docs/DeveloperPolicy.html
diff -u llvm/docs/DeveloperPolicy.html:1.24 llvm/docs/DeveloperPolicy.html:1.25
--- llvm/docs/DeveloperPolicy.html:1.24	Sun Feb 18 23:57:29 2007
+++ llvm/docs/DeveloperPolicy.html	Sun Feb 18 23:59:30 2007
@@ -24,13 +24,6 @@
     </ol></li>
     <li><a href="#attribution">Attribution of Changes</a></li>
   </ol></li>
-  <li><a href="#patches">Patch Policies</a>
-  <ol>
-    <li><a href="#p_form">Patch Form</a></li>
-    <li><a href="#p_submission">Patch Submission</a></li>
-    <li><a href="#p_aftersub">After Submission</a></li>
-    <li><a href="#p_aftercommit">After Commit</a></li>
-  </ol></li>
   <li><a href="#candl">Copyright and License</a>
   <ol>
     <li><a href="#copyright">Copyright</a></li>
@@ -310,12 +303,15 @@
     <li>The remaining inter-related work should be decomposed into unrelated 
     sets of changes if possible.  Once this is done, define the first increment
     and get consensus on what the end goal of the change is.</li>
-    <li>Increments can be stand alone (e.g. to fix a bug), or part of a planned
-    series of increments towards some development goal.</li>
-    <li>Increments should be kept as small as possible. This simplifies your 
+    
+    <li>Each change in the set can be stand alone (e.g. to fix a bug), or part
+    of a planned series of changes that works towards the development goal.</li>
+    
+    <li>Each change should be kept as small as possible. This simplifies your 
     work (into a logical progression), simplifies code review and reduces the
     chance that you will get negative feedback on the change. Small increments
     also facilitate the maintenance of a high quality code base.</li>
+    
     <li>Often, an independent precursor to a big change is to add a new API and
         slowly migrate clients to use the new API.  Each change to use the new
         API is often "obvious" and can be committed without review.  Once the 
@@ -460,7 +456,7 @@
   Written by: the 
   <a href="mailto:llvm-oversight at cs.uiuc.edu">LLVM Oversight Group</a><br>
   <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2007/02/19 05:57:29 $
+  Last modified: $Date: 2007/02/19 05:59:30 $
 </address>
 </body>
 </html>






More information about the llvm-commits mailing list