[patch] hb-policy-etiquette.xml.diff

hb-policy-etiquette.xml.diff (text/plain), 3.52 KB, created by Karl Trygve Kalleberg (RETIRED) on 2004-09-05 04:36:52 UTC

Index: hb-policy-etiquette.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml,v
retrieving revision 1.5
diff -u -r1.5 hb-policy-etiquette.xml
--- hb-policy-etiquette.xml	20 Jul 2004 08:54:34 -0000	1.5
+++ hb-policy-etiquette.xml	5 Sep 2004 11:32:54 -0000
@@ -23,7 +23,7 @@
 however that all developers maintain reasonable standards of behaviour
 with our community - whether to other developers or users.  However,
 you may be subject to sanctions or a suspension if a resonable
-standard is not.
+standard is not met.
 </p>
 
 <p>
@@ -80,8 +80,8 @@
 <ul>
   <li>
     Make your ChangeLogs readable to the average end-user: try to keep
-    things simple and short if you can but provide any critical
-    information if you need to. Remember that ChangeLogs need to be
+    things simple and short if you can, but provide any critical
+    information as needed. Remember that ChangeLogs need to be
     written in good, "correct" English even if they are
     short. Punctuation is essential.
   </li>
@@ -132,16 +132,28 @@
   <li>
     Try to not bump ebuilds continuously unless there really <b>is</b> a
     benefit or a security fix which is important. Unnecessary examples
-    of bumping include situations where a patch for the support of a
-    new kernel version is added, for example; unless the ebuild is out
-    of date from the date of the bug report.
-  </li>
-  <li>
-    Try to not make ebuilds do unnecessary steps or do things outside of
-    the package which may be un-needed: packaging unsupported
-    patches as an "addition" is a bad idea unless they are either
-    tested well by both you and your target audience and that they
-    are code-checked for security.
+    of bumping include:
+    <ul>
+      <li>
+        You change minor spelling errors in script file comments, script file
+        indentation or similar.
+      </li>
+      <li>
+        You patch your non-kernel ebuild to support a new kernel version (or
+        a new version of a library), allowing more users to install your ebuild,
+        but not changing anything for existing users of the current revision.
+      </li>
+    </ul>
+    As a general rule, fixes with non-trivial changes to any of the installed
+    files of any ebuild warrant a revision bump. Put differently: If your fix
+    changes the behaviour for existing users, you bump so that they will
+    upgrade.
+  </li>
+  <li>
+    Try to not make ebuilds preform unnecessary steps. Packaging unsupported
+    patches unsupported patches as an "addition" is a bad idea unless they
+    are thoroughly tested by you, widely used, and audited for security
+    vulnerabilities.
   </li>
   <li>
     Ebuilds should be well commented if non-standard code or large
@@ -151,11 +163,10 @@
     don't shower the user with a stream of information.
   </li>
   <li>
-    Respect developers' coding preferences and don't change the
-    ebuild syntax to remove stress on the CVS server, and to make
-    things simpler for everybody unless you feel there is a real
-    benefit in adding syntax cleanups - for example, faster
-    compilation or a better more verbose output to the end-user.
+    Respect developers' coding preferences. Unneccessarily changing the syntax
+    of an ebuild increases the load on the CVS server and can cause complications
+    for others. Syntax changes should only be done if there is a real benefit,
+    such as faster compilation or improved information for the end user.
   </li>
 </ul>