debian-policy--devel--3.0 is sealed, look at debian-policy--devel--3.6

[debian/debian-policy.git] / policy-process.sgml

diff --git a/policy-process.sgml b/policy-process.sgml
index 15eb7c77e87cad45b20cb18aa525285dd6adc040..ca5fe05849a3781b12298b6df8aa067196c3b4a4 100644 (file)
--- a/policy-process.sgml
+++ b/policy-process.sgml
@@ -7,9 +7,9 @@
        <name>Manoj Srivastava</name>
         <email>srivasta@debian.org</email>
       </author>
-      <version>$Revision: 1.3 $</version>
+      <version>$Revision: 1.7 $</version>
       <copyright>
-        <copyrightsummary>Copyright &#169; 2000 by Manoj Srivastava. 
+        <copyrightsummary>Copyright &copy; 2000 by Manoj Srivastava. 
         </copyrightsummary>
         <p>
           You are given permission to redistribute this document
@@ -22,6 +22,7 @@
           <tt>/usr/share/common-licenses/GPL</tt>. </p>
       </copyright>
     </titlepag>
+    <toc detail="sect">
     <chapt>
       <heading>Introduction, and Administrivia</heading>
       <p>
@@ -49,8 +50,46 @@
        <em>In the following, the term developer refers to registered
          Debian developers.</em>
       </p>
-      <p>A copy of this document should also be found at <url
-      id="http://master.debian.org/~srivasta/policy/"></p>      
+      <sect>
+       <heading>Guideliens for policy change proposals</heading>
+       <p>
+         Policy does not document all existing practice.  It only
+         incorporates a minimal ruleset that is required for systems
+         integration (usually selecting one branch from several
+         equally viable technical options). It is not a best
+         practices document.
+       </p>
+       <p>
+         Policy changes under this procedure also should almost never
+         (unless directed by the tech-ctte, and perhaps the DPL)
+         cause a change that would make a significant chunk of
+         packages instantly buggy; for such changes, it is better to
+         implement a gradual transition plan, allowing for partial
+         upgrades (and perhaps using release goals as
+         motivators). Part of the rationale for this is common sense;
+         a global change, in the past, has taken time, and having
+         either a large number of RC bugs, or ignoring a large number
+         of bugs that would otherwise be RC seems silly; and, anyway,
+         there are concerns that the policy group does not really
+         have the power to change policy drastically. This is the
+         basis of the policy shall not be used as a stick to beat
+         developers with.
+       </p>
+
+       <p>
+         Nor does policy <em>always</em> document only existing
+         practices.  What that oft misquoted statement refers to was
+         a part of was a larger thesis that is meant to suggest that
+         policy is not the place for testing out design; if a
+         complicated technical proposal is to be made into policy, it
+         should be independently implemented, have all the kinks
+         worked out, and then have that working model be implemented
+         as policy.  Having to change policy back and forth while a
+         design is being worked out needs be avoided.
+       </p>
+
+      </sect>
+  
     </chapt>
     <chapt>
       <heading>Archives and Personnel</heading>