updated the when-to-do-source-NMUs section a little bit, prompted by Elie Rosenblum...

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1808 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developers-reference.sgml b/developers-reference.sgml
index b90515e765084b49616f19312f59eb4fc395fba8..9d1de5ce74be7fd7657ea3d2e0079152856611ca 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.126 $">
+  <!entity cvs-rev "$Revision: 1.127 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -1869,14 +1869,14 @@ maintainer of the package; they might be just about to upload a fix
 for the problem.  As with any source NMU, the guidelines found in <ref
 id="nmu-guidelines"> need to be followed.
        <p>
-Bug fixes to unstable by non-maintainers are also acceptable, but only
-as a last resort or with permission.  The following protocol should
-be respected to do an NMU:
+Uploading bug fixes to unstable by non-maintainers should only be done
+by following this protocol:
        <p>
 <list>
            <item>
-Make sure that the package's bug is in the Debian Bug Tracking System
-(BTS).  If not, submit a bug.  
+Make sure that the package's bugs that the NMU is meant to address are all
+filed in the Debian Bug Tracking System (BTS).
+If they are not, submit them immediately.
            <item>
 Wait a few days the response from the maintainer. If you don't get
 any response, you may want to help him by sending the patch that fixes
@@ -1897,7 +1897,15 @@ to cancel the NMU.
 Follow what happens, you're responsible for any bug that you introduced
 with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
 to stay informed of the state of the package after your NMU.
-         </list>
+</list>
+       <p>
+At times, the release manager or an organized group of developers can
+announce a certain period of time in which the NMU rules are relaxed.
+This usually involves shortening the period during which one is to wait
+before uploading the fixes, and shortening the DELAYED period. It is
+important to notice that even in these so-called "bug squashing party"
+times, the NMUer has to file bugs and contact the developer first,
+and act later.
 
       <sect1 id="nmu-guidelines">How to do a source NMU
        <p>