replaced evil latin1-only «» quotation marks, replaced mentions of important severity...

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

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 380a9897c5130444ca23040bac8a196f18b09a1b..4149d206a6f458a9055d7d99d77e2e2eb154f539 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -5,7 +5,7 @@
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.45 $">
+  <!entity cvs-rev "$Revision: 1.46 $">
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
@@ -310,9 +310,9 @@ In order to inform the other developers, there's two things that you should do.
 First send a mail to &email-debian-private; giving the period of time when
 you will be on vacation.  You can also give some special instructions on what to
 do if any problem occurs. Next you should update your information
-available in the Debian LDAP database and mark yourself as « on vacation »
+available in the Debian LDAP database and mark yourself as ``on vacation''
 (this information is only accessible to debian developers). Don't forget
-to remove the « on vacation » flag when you come back.
+to remove the ``on vacation'' flag when you come back.
 
       <sect id="upstream-coordination">Coordination With Upstream Developers
        <p>
@@ -336,9 +336,9 @@ need, always try not to fork from the upstream sources.
 
       <sect id="rc-bugs">Managing Release Critical Bugs
         <p>
-Release Critical Bugs (RCB) are the bugs of severity
-«&nbsp;critical&nbsp;», «&nbsp;grave&nbsp;» and
-«&nbsp;important&nbsp;». Those bugs can delay the Debian release
+Release Critical Bugs (RCB) are all bugs that have severity
+<em>critical</em>, <em>grave</em> or <em>serious</em>.
+Those bugs can delay the Debian release
 and/or can justify the removal of a package at freeze time. That's why
 those bugs needs to be corrected as fast as possible.  You must be
 aware that some developers who are part of the <url
@@ -419,7 +419,7 @@ other mailing lists are available for a variety of special topics; see
 <url id="&url-debian-lists-subscribe;"> for a list.  Cross-posting
 (sending the same message to multiple lists) is discouraged.
        <p>
-&email-debian-private; is a special mailing lists for private
+&email-debian-private; is a special mailing list for private
 discussions amongst Debian developers.  It is meant to be used for
 posts which for whatever reason should not be published publically.
 As such, it is a low volume list, and users are urged not to use
@@ -976,15 +976,15 @@ some guidelines:
 <list>
                <item>
 Fixes for bugs of severity <em>critical</em>, <em>grave</em>, or
-<em>important</em> severity are always allowed for those packages that
+<em>serious</em> severity are always allowed for those packages that
 must exist in the final release
                <item>
-<em>critical</em>, <em>grave</em>, and <em>important</em> bug fixes
-are only allowed for non-necessary packages if they don't add any new
+<em>critical</em>, <em>grave</em>, and <em>serious</em> bug fixes are
+allowed for non-necessary packages but only if they don't add any new
 features
                <item>
-normal bug fixes are allowed (though discouraged) on all packages if
-and only if there are no new features
+important, normal and minor bug fixes are allowed (though discouraged)
+on all packages if and only if there are no new features
                <item>
 wishlist fixes are not allowed (they are, after all, not really bugs)
                <item>
@@ -1287,7 +1287,7 @@ cannot be reached in time, the Security Manager may upload a fixed
 package (i.e., do a source NMU).
        <p>
 During the release freeze (see <ref id="upload-frozen">), NMUs which
-fix important or higher severity bugs are encouraged and accepted.
+fix serious or higher severity bugs are encouraged and accepted.
 Even during this window, however, you should endeavor to reach the
 current maintainer of the package; they might be just about to upload
 a fix for the problem.  As with any source NMU, the guidelines found
@@ -1586,7 +1586,7 @@ the porting effort, at the discretion of the porter group.  (Remember,
 none of this is Policy, just mutually agreed upon guidelines.)
          <p>
 Secondly, porters doing source NMUs should make sure that the bug they
-submit to the BTS should be of severity `important' or greater.  This
+submit to the BTS should be of severity `serious' or greater.  This
 ensures that a single source package can be used to compile every
 supported Debian architecture by release time.  It is very important
 that we have one version of the binary and source package for all