Be somewhat less discouraging about NMU changes to packaging style, and NMUing new...

diff --git a/debian/changelog b/debian/changelog
index 029d21fcddb5ff4a35778af2f1708300f8b9ffd0..c07b49af66a971dfd8803bb61fae3d9098f6ad1d 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,9 @@ developers-reference (3.4.14~~iwj) UNRELEASED; urgency=low
 
   [ Ian Jackson ]
   * Salvaging by NMUing Maintainer update (as discussed at DC14).
+  * Be somewhat less discouraging about NMU changes to packaging style,
+    and NMUing new upstream versions.  But, break these imprecations out
+    into a separate bullet point to make them clearer.
 
  --
 

diff --git a/pkgs.dbk b/pkgs.dbk
index f7750c8ca9f3cef3ea1c28db7814a6956cf079d4..53ffb9822a4ac7c78e3e61c5de956dc54347528b 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1987,9 +1987,17 @@ reviews of the NMU diff.
 <para>
 Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
 wishlist bugs for packaging a new upstream version, but care should be
-taken to minimize the impact to the maintainer.) Fixing cosmetic issues
-or changing the packaging style (e.g. switching from cdbs to dh) in NMUs
-is discouraged.
+taken to minimize the impact to the maintainer.)  Addressing stylistic
+issues which are matters of taste should be done in consultation with
+the maintainer.
+</para>
+</listitem>
+<listitem>
+<para>
+Start small.  Large changes (new upstream versions, or changing the
+packaging style e.g. switching to dh) should not be done in the first
+NMU of a package unless absolutely necessary, and should generally be
+uploaded to substantially DELAYED queues.
 </para>
 </listitem>
 <listitem>