chiark / gitweb /
typo and language fixes; key replacement more detailed
authoraba <aba@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 7 Nov 2004 11:57:25 +0000 (11:57 +0000)
committeraba <aba@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 7 Nov 2004 11:57:25 +0000 (11:57 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2631 313b444b-1b9f-4f58-a734-7bb04f332e8d

common.ent
debian/changelog
developers-reference.sgml

index dce61a6..13a8572 100644 (file)
@@ -11,7 +11,7 @@
 <!-- volatile information -->
 
 <!ENTITY number-of-pkgs "9000">
-<!ENTITY number-of-maintainers "800">
+<!ENTITY number-of-maintainers "900">
 
 <!ENTITY number-of-arches "12">
 
index 02f8243..f263d12 100644 (file)
@@ -29,6 +29,8 @@ developers-reference (3.3.5) unstable; urgency=low
       + add -B for binNMUs, and local debsign usage. Closes: #208839.
       + warning about breaking all-packages by binNMU. Closes: #213348.
     - add information about gpg usage. Closes: #175815.
+    - make key replacement instructions more details. Closes: #275921
+    - typo and language fixes. Thanks, Era Eriksson. Closes: #277576
   * Matt Zimmerman
     - Security uploads get urgency=high
     - Be even more explicit about not uploading security updates
index d60929d..5443f11 100644 (file)
@@ -6,7 +6,7 @@
   <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.245 $">
+  <!ENTITY cvs-rev "$Revision: 1.246 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -87,7 +87,7 @@ id="&url-debian-policy;" name="Debian Policy Manual">.
       <p>
 Furthermore, this document is <em>not an expression of formal
 policy</em>.  It contains documentation for the Debian system and
-generally agreed-upon best practices.  Thus, it is what is called a
+generally agreed-upon best practices.  Thus, it is not what is called a
 ``normative'' document.
 
 
@@ -116,14 +116,14 @@ to work on something to avoid duplicated effort.
        <p>
 Another good list to subscribe to is &email-debian-mentors;.  See <ref
 id="mentors"> for details.  The IRC channel <tt>#debian</tt> can also be
-helpful.
+helpful; see <ref id="irc-channels">.
 
        <p>
 When you know how you want to contribute to &debian-formal;, you
 should get in contact with existing Debian maintainers who are working
 on similar tasks.  That way, you can learn from experienced developers.
 For example, if you are interested in packaging existing software for
-Debian you should try to get a sponsor.  A sponsor will work together
+Debian, you should try to get a sponsor.  A sponsor will work together
 with you on your package and upload it to the Debian archive once they
 are happy with the packaging work you have done.  You can find a sponsor
 by mailing the &email-debian-mentors; mailing list, describing your
@@ -157,7 +157,7 @@ The process of registering as a developer is a process of verifying
 your identity and intentions, and checking your technical skills.  As
 the number of people working on &debian-formal; has grown to over
 &number-of-maintainers; people and our systems are used in several
-very important places we have to be careful about being compromised.
+very important places, we have to be careful about being compromised.
 Therefore, we need to verify new maintainers before we can give them
 accounts on our servers and let them upload packages.
        <p>
@@ -175,7 +175,7 @@ has been signed by an existing Debian maintainer.  If your GnuPG key
 is not signed yet, you should try to meet a Debian maintainer in
 person to get your key signed.  There's a <url id="&url-gpg-coord;"
 name="GnuPG Key Signing Coordination page"> which should help you find
-a maintainer close to you (If you cannot find a Debian maintainer
+a maintainer close to you. (If you cannot find a Debian maintainer
 close to you, there's an alternative way to pass the ID check.  You
 can send in a photo ID signed with your GnuPG key.  Having your GnuPG
 key signed is the preferred way, however.  See the
@@ -197,9 +197,10 @@ You can use some other implementation of OpenPGP as well.  Note that
 OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
 2440">.
        <p>
+<!-- FIXME: DSS is not exactly equivalent to DSA, is it? -->
 The recommended public key algorithm for use in Debian development
-work is DSA (sometimes call ``DSS'' or ``DH/ElGamal'').  Other key
-types may be used however.  Your key length must be at least 1024
+work is DSA (sometimes called ``DSS'' or ``DH/ElGamal'').
+Other key types may be used, however.  Your key length must be at least 1024
 bits; there is no reason to use a smaller key, and doing so would be
 much less secure.  Your key must be signed with at least your own user
 ID; this prevents user ID tampering.  <prgn>gpg</prgn> does this
@@ -296,9 +297,19 @@ your key is lost.
        <p>
 If you add signatures to your public key, or add user identities, you
 can update the Debian key ring by sending your key to the key server at
-<tt>&keyserver-host;</tt>.  If you need to add a completely new key,
-or remove an old key, send mail to &email-debian-keyring;.  The same
-key extraction routines discussed in <ref id="registering"> apply.
+<tt>&keyserver-host;</tt>.
+       <p>
+If you need to add a completely new key or remove an old key, you need
+to get the new key signed by another developer. After this, a mail
+signed by another developer listing your account name, the keyids
+of the old and of the new key and the reason should be send to
+&email-debian-keyring;. If the old key is compromised or invalid, you
+also have to add the revocation certificate. If there is no real
+reason for a new key, the Keyring Maintainers will only accept it if
+it's more secure and connected to the old key.
+       <p>
+The same key extraction routines discussed in <ref id="registering">
+apply. 
        <p>
 You can find a more in-depth discussion of Debian key maintenance in
 the documentation of the <package>debian-keyring</package> package.
@@ -524,7 +535,7 @@ on Debian, it's not a support channel (there's <em>#debian</em> for that).
 It is however open to anyone who wants to lurk (and learn). Its topic is
 commonly full of interesting information for developers.
        <p>
-Since <em>#debian-devel</em> it's an open channel, you
+Since <em>#debian-devel</em> is an open channel, you
 should not speak there of issues that are discussed in
 &email-debian-private;. There's another channel for this purpose,
 it's called <em>#debian-private</em> and it's protected by a key.
@@ -536,7 +547,9 @@ all the files.
 There are other additional channels dedicated to specific subjects.
 <em>#debian-bugs</em> is used for coordinating bug squash parties.
 <em>#debian-boot</em> is used to coordinate the work on the boot
-floppies (i.e., the installer). <em>#debian-doc</em> is
+floppies (i.e., the installer).
+<!-- FIXME: is boot-floppies an anachronism, or still the channel name? -->
+<em>#debian-doc</em> is
 occasionally used to talk about documentation, like the document you are
 reading. Other channels are dedicated to an architecture or a set of
 packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
@@ -555,8 +568,9 @@ id="http://www.oftc.net/"> IRC network.
 
       <sect id="doc-rsrcs">Documentation
        <p>
-This document contains a lot of information very useful to Debian developers,
-but it can not contain everything. Most of the other interesting documents
+This document contains a lot of information
+which is useful to Debian developers,
+but it cannot contain everything. Most of the other interesting documents
 are linked from <url id="&url-devel-docs;" name="The Developers' Corner">.
 Take the time to browse all the links, you will learn many more things.
 
@@ -601,7 +615,7 @@ generally you'll report a bug against a ``pseudo-package''.  See <ref
 id="submit-bug"> for information on how to submit bugs.
        <p>
 Some of the core servers are restricted, but the information from there
-is mirror to another server.
+is mirrored to another server.
 
       <sect1 id="servers-bugs">The bugs server
        <p>
@@ -640,7 +654,7 @@ Problems with the non-US package archive should generally be submitted as
 bugs against the <package>nonus.debian.org</package> pseudo-package (notice
 the lack of hyphen between "non" and "us" in the pseudo-package name
 &mdash; that's for backwards compatibility). Remember to check whether or
-not someone else has already reported the problem on the
+not someone else has already reported the problem to the
 <url id="http://&bugs-host;/nonus.debian.org" name="Bug Tracking System">.
 
       <sect1 id="servers-www">The www-master server
@@ -652,7 +666,7 @@ of Debian for most newbies.
 If you find a problem with the Debian web server, you should generally
 submit a bug against the pseudo-package,
 <package>www.debian.org</package>. Remember to check whether or not someone
-else has already reported the problem on the
+else has already reported the problem to the
 <url id="http://&bugs-host;/www.debian.org" name="Bug Tracking System">.
 
       <sect1 id="servers-people">The people web server
@@ -678,6 +692,7 @@ aforementioned <tt>non-us.debian.org</tt>.
 Send mail to &email-debian-devel; if you have any questions.
 
       <sect1 id="servers-cvs">The CVS server
+<!-- TODO: document svn.debian.org also -->
        <p>
 Our CVS server is located on <tt>cvs.debian.org</tt>.
        <p>
@@ -736,7 +751,7 @@ Most of the information is not accessible to the public, naturally.
 For more information please read the online documentation that you can find
 at <url id="&url-debian-db-doc;">.
        <p>
-One can also submit their SSH keys to be used for authorization on the
+Developers can also submit their SSH keys to be used for authorization on the
 official Debian machines, and even add new *.debian.net DNS entries.
 Those features are documented at <url id="&url-debian-db-mail-gw;">.
 
@@ -818,7 +833,7 @@ package licenses of the packages in <em>non-free</em> and include as
 many on the CD-ROMs as he's allowed to. (Since this varies greatly from
 vendor to vendor, this job can't be done by the Debian developers.)
        <p>
-Note also that the term "section" is also used to refer to categories
+Note that the term "section" is also used to refer to categories
 which simplify the organization and browsing of available packages, e.g.
 <em>admin</em>, <em>net</em>, <em>utils</em> etc. Once upon a time, these
 sections (subsections, rather) existed in the form of subdirectories within
@@ -848,7 +863,7 @@ also have ports underway to non-Linux kernels.  Aside from
 shipped for <em>i386</em> and <em>m68k</em> architectures.  Debian 2.1
 ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
 <em>sparc</em> architectures.  Debian 2.2 added support for the
-<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 adds
+<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 added
 support of five new architectures: <em>ia64</em>, <em>hppa</em>,
 <em>s390</em>, <em>mips</em> and <em>mipsel</em>.
        <p>
@@ -894,7 +909,7 @@ server.  For instance, at the mirror site,
 contained in <ftppath>/debian</ftppath>, which is a common location
 (another is <file>/pub/debian</file>).
        <p>
-A distribution is comprised of Debian source and binary packages, and the
+A distribution comprises Debian source and binary packages, and the
 respective <file>Sources</file> and <file>Packages</file> index files, containing
 the header information from all those packages. The former are kept in the
 <file>pool/</file> directory, while the latter are kept in the <file>dists/</file>
@@ -904,8 +919,8 @@ directory of the archive (for backwards compatibility).
        <sect2 id="sec-dists">Stable, testing, and unstable
        <p>
 There are always distributions called <em>stable</em> (residing in
-<file>dists/stable</file>), one called <em>testing</em> (residing in
-<file>dists/testing</file>), and one called <em>unstable</em> (residing in
+<file>dists/stable</file>), <em>testing</em> (residing in
+<file>dists/testing</file>), and <em>unstable</em> (residing in
 <file>dists/unstable</file>). This reflects the development process of the
 Debian project.
        <p>
@@ -913,7 +928,7 @@ Active development is done in the <em>unstable</em> distribution
 (that's why this distribution is sometimes called the <em>development
 distribution</em>). Every Debian developer can update his or her
 packages in this distribution at any time. Thus, the contents of this
-distribution changes from day-to-day. Since no special effort is done
+distribution change from day to day. Since no special effort is made
 to make sure everything in this distribution is working properly, it is
 sometimes literally unstable.
        <p>
@@ -1015,9 +1030,9 @@ New software which isn't likely to damage your system can go directly into
 An alternative to <em>experimental</em> is to use your personal web space
 on <tt>people.debian.org</tt>.
          <p>
-Please consider to use the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
-if uploading a package to unstable to get the bugs finally closed that were
-first fixed in experimental.
+When uploading to unstable a package which had bugs fixed in experimental,
+please consider using the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
+to finally get them closed.
 
       <sect1 id="codenames">Release code names
        <p>
@@ -1095,14 +1110,14 @@ the <prgn>katie</prgn> script, which verifies the integrity of the uploaded
 packages and their cryptographic signatures.
 If the package is considered ready to be installed, it
 is moved into the <file>accepted</file> directory. If this is the first upload of
-the package, it is moved in the <file>new</file> directory, where it waits
-for an approval of the ftpmasters. If the package contains files to be installed
-"by-hand" it is moved in the <file>byhand</file> directory, where it waits
-for manual installation by the ftpmasters. Otherwise, if any error has been detected,
-the package is refused and is moved in the <file>reject</file> directory.
-       <p>
-Once the package is accepted the system sends a confirmation
-mail to the maintainer, closes all the bugs marked as fixed by the upload
+the package, it is moved to the <file>new</file> directory, where it waits
+for approval by the ftpmasters. If the package contains files to be installed
+"by hand" it is moved to the <file>byhand</file> directory, where it waits
+for manual installation by the ftpmasters. Otherwise, if any error has been detected,
+the package is refused and is moved to the <file>reject</file> directory.
+       <p>
+Once the package is accepted, the system sends a confirmation
+mail to the maintainer and closes all the bugs marked as fixed by the upload,
 and the auto-builders may start recompiling it. The package is now publicly
 accessible at <url id="&url-incoming;"> (there is no
 such URL for packages in the non-US archive) until it is really installed
@@ -1122,11 +1137,11 @@ or `experimental', the announcement will be posted to
 &email-debian-devel-changes; instead.
        <p>
 All Debian developers have write access to the <file>unchecked</file>
-directory in order to upload their packages, they also have that access
+directory in order to upload their packages; they also have that access
 to the <file>reject</file> directory in order to remove their bad uploads
-or to move some files back in the <file>unchecked</file> directory. But
-all the other directories are only writable by the ftpmasters, that is
-why you can not remove an upload once it has been accepted.
+or to move some files back to the <file>unchecked</file> directory. But
+all the other directories are only writable by the ftpmasters, which is
+why you cannot remove an upload once it has been accepted.
 
       <sect1 id="delayed-incoming-broken">Delayed incoming
        <p>
@@ -1136,17 +1151,17 @@ the currently working way.
        <p>
 The <file>unchecked</file> directory has a special <file>DELAYED</file>
 subdirectory. It is itself subdivided in nine directories
-called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded in
-one of those directories will be moved in the real unchecked
+called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded to
+one of those directories will be moved to the real unchecked
 directory after the corresponding number of days.
-This is done by a script that is run each day and which moves the
+This is done by a script which is run each day and which moves the
 packages between the directories. Those which are in "1-day" are
-installed in <file>unchecked</file> while the others are moved in the 
+installed in <file>unchecked</file> while the others are moved to the 
 adjacent directory (for example, a package in <file>5-day</file> will
-be moved in <file>4-day</file>). This feature is particularly useful
+be moved to <file>4-day</file>). This feature is particularly useful
 for people who are doing non-maintainer uploads. Instead of
 waiting before uploading a NMU, it is uploaded as soon as it is
-ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
+ready, but to one of those <file>DELAYED/<var>x</var>-day</file> directories.
 That leaves the corresponding number of days for the maintainer
 to react and upload another fix themselves if they are not
 completely satisfied with the NMU. Alternatively they can remove
@@ -1182,7 +1197,7 @@ Each package has several dedicated web pages.
 displays each version of the package
 available in the various distributions.  Each version links to a page
 which provides information, including the package description,
-the dependencies and package download links.
+the dependencies, and package download links.
        <p>
 The bug tracking system tracks bugs for each package.
 You can view the bugs of a given package at the URL
@@ -1207,7 +1222,7 @@ libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386,
        <p>
 In this example, you can see that the version in <em>unstable</em> differs from
 the version in <em>testing</em> and that there has been a binary-only NMU of the
-package for the alpha architecture. Each time the package has been
+package for the alpha architecture. Each version of the package has been
 recompiled on most of the architectures.
 
     <sect id="pkg-tracking-system">The Package Tracking System
@@ -1365,7 +1380,7 @@ X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
        <sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
        <p>
 If you use a publicly accessible CVS repository for maintaining
-your Debian package you may want to forward the commit notification
+your Debian package, you may want to forward the commit notification
 to the PTS so that the subscribers (and possible co-maintainers) can
 closely follow the package's evolution.
        <p>
@@ -1505,7 +1520,7 @@ you must then submit a bug report (<ref id="submit-bug">) against the
 pseudo-package <package>wnpp</package> 
 describing your plan to create a new package, including, but not
 limiting yourself to, a description of the package, the license of the
-prospective package and the current URL where it can be downloaded
+prospective package, and the current URL where it can be downloaded
 from.
        <p>
 You should set the subject of the bug to ``ITP: <var>foo</var>
@@ -1516,10 +1531,10 @@ to <em>wishlist</em>. If you feel it's necessary, send a copy to
 of the message (no, don't use <tt>CC:</tt>, because that way the message's subject
 won't indicate the bug number).
        <p>
-Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry on the
+Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry in the
 changelog of the new package in order for the bug report to be
-automatically closed once the new package is installed on the archive
-(<ref id="upload-bugfix">).
+automatically closed once the new package is installed in the archive
+(see <ref id="upload-bugfix">).
        <p>
 There are a number of reasons why we ask maintainers to announce their
 intentions:
@@ -1736,11 +1751,12 @@ the changes file last.  Otherwise, your upload may be rejected because the
 archive maintenance software will parse the changes file and see that not
 all files have been uploaded.
          <p>
+<!-- FIXME: is this still topical? Explain the rationale? -->
 <em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
 packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
 such software should go to <tt>non-us</tt> (see <ref
 id="upload-non-us">). Furthermore packages containing code that is
-patent-restricted by the United States government can not be uploaded to
+patent-restricted by the United States government cannot be uploaded to
 <tt>ftp-master</tt>; depending on the case they may still be uploaded to
 <file>non-US/non-free</file> (it's in non-free because of distribution issues
 and not because of the license of the software). If you can't upload it to
@@ -1826,14 +1842,14 @@ For details, please see section <ref id="bug-security">.
 
        <sect1>Other upload queues
          <p>
-The scp queues on ftp-master, non-us and security are mostly unuseable
+The scp queues on ftp-master, non-us, and security are mostly unusable
 due to the login restrictions on those hosts.
          <p>
 The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
 currently down. Work is underway to resurrect those. 
          <p>
-The queues on master.debian.org, samosa.debian.org, master.debian.or.jp
-and ftp.chiark.greenend.org.uk are down permanently and will not be
+The queues on master.debian.org, samosa.debian.org, master.debian.or.jp,
+and ftp.chiark.greenend.org.uk are down permanently, and will not be
 resurrected. The queue in Japan will be replaced with a new queue on
 hp.debian.or.jp some day.
          <p>
@@ -1863,7 +1879,7 @@ The installation notification also includes information on what
 section the package was inserted into.  If there is a disparity, you
 will receive a separate email notifying you of that.  Read on below.
        <p>
-Note also that if you upload via queues, the queue daemon software will
+Note that if you upload via queues, the queue daemon software will
 also send you a notification by email.
 
     <sect id="override-file">Specifying the package section, subsection and priority
@@ -1909,10 +1925,10 @@ tracking system" id="&url-bts;">. This includes knowing how to file bug
 reports properly (see <ref id="submit-bug">), how to update them and
 reorder them, and how to process and close them.
        <p>
-The bug tracking system's features interesting to developers are described
+The bug tracking system's features are described
 in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
 This includes closing bugs, sending followup messages, assigning severities
-and tags, marking bugs as forwarded and other issues.
+and tags, marking bugs as forwarded, and other issues.
        <p>
 Operations such as reassigning bugs to other packages, merging separate
 bug reports about the same issue, or reopening bugs when they are
@@ -1973,7 +1989,7 @@ closed.
        <p>
 As a package maintainer, you will often find bugs in other packages or
 have bugs reported against your packages which are actually bugs in
-other packages. The bug tracking system's features interesting to developers
+other packages. The bug tracking system's features
 are described in the <url id="&url-bts-devel;" name="BTS documentation for
 Debian developers">. Operations such as reassigning, merging, and tagging
 bug reports are described in the <url id="&url-bts-control;" name="BTS
@@ -1981,7 +1997,7 @@ control server documentation">. This section contains
 some guidelines for managing your own bugs, based on the collective
 Debian developer experience.
         <p>
-Filing bugs for problems that  you find in other packages is one of
+Filing bugs for problems that you find in other packages is one of
 the "civic obligations" of maintainership, see <ref id="submit-bug">
 for details. However, handling the bugs in your own packages is
 even more important.
@@ -1997,7 +2013,7 @@ to the good documentation and so on). If the same report comes up
 again and again you may ask yourself if the documentation is good
 enough or if the program shouldn't detect its misuse in order to
 give an informative error message. This is an issue that may need
-to be brought to the upstream author.
+to be brought up with the upstream author.
     <p>
 If the bug submitter disagrees with your decision to close the bug,
 they may reopen it until you find an agreement on how to handle it.
@@ -2036,7 +2052,7 @@ Forwarding a bug is not enough, you have to check at each release if
 the bug has been fixed or not. If it has, you just close it, otherwise
 you have to remind the author about it. If you have the required skills
 you can prepare a patch that fixes the bug and that you send at the
-same time to the author. Make sure to send the patch in the BTS and to
+same time to the author. Make sure to send the patch to the BTS and to
 tag the bug as <tt>patch</tt>.
     <item>
 If you have fixed a bug in your local copy, or if a fix has been
@@ -2388,7 +2404,7 @@ cases.
        <p>
 Sometimes a package will change its section.  For instance, a
 package from the `non-free' section might be GPL'd in a later version,
-in which case, the package should be moved to `main' or
+in which case the package should be moved to `main' or
 `contrib'.<footnote> See the <url id="&url-debian-policy;"
 name="Debian Policy Manual"> for guidelines on what section a package
 belongs in.
@@ -2561,9 +2577,9 @@ porters, and make their jobs unnecessarily difficult.
        <p>
 The first and most important thing is to respond quickly to bug or
 issues raised by porters.  Please treat porters with courtesy, as if
-they were in fact co-maintainers of your package (which in a way, they
-are).  Please be tolerant of succinct or even unclear bug reports,
-doing your best to hunt down whatever the problem is.
+they were in fact co-maintainers of your package (which, in a way, they
+are).  Please be tolerant of succinct or even unclear bug reports;
+do your best to hunt down whatever the problem is.
        <p>
 By far, most of the problems encountered by porters are caused by
 <em>packaging bugs</em> in the source packages.  Here is a checklist
@@ -2611,7 +2627,7 @@ or programs.  For instance, you should never be calling programs in
 being setup in a special way.  Try building your package on another
 machine, even if it's the same architecture.
            <item>
-Don't depend on the package you're building already being installed (a
+Don't depend on the package you're building being installed already (a
 sub-case of the above issue).
            <item>
 Don't rely on the compiler being a certain version, if possible.  If
@@ -2648,7 +2664,7 @@ binary-only build of only the architecture-dependent portions of the
 package, using the `binary-arch' target in <file>debian/rules</file>.
        <p>
 If you are working on a Debian machine for your porting efforts and you
-need to sign your upload locally for the acceptance in the archive, you
+need to sign your upload locally for its acceptance in the archive, you
 can run <prgn>debsign</prgn> on your <file>.changes</file> file to have
 it signed conveniently, or use the remote signing mode of <prgn>dpkg-sig</prgn>.
 
@@ -2666,7 +2682,7 @@ version number greater than the currently available one).
        <p>
 You have to make sure that your binary-only NMU doesn't render the package
 uninstallable. This could happen when a source package generates
-arch-dependend and arch-independend packages that depend on each other via
+arch-dependent and arch-independent packages that depend on each other via
 $(Source-Version).
        <p>
 Despite the
@@ -2726,7 +2742,7 @@ architecture in order to comply with many licenses.
 Porters should try to avoid patches which simply kludge around bugs in
 the current version of the compile environment, kernel, or libc.
 Sometimes such kludges can't be helped.  If you have to kludge around
-compilers bugs and the like, make sure you <tt>#ifdef</tt> your work
+compiler bugs and the like, make sure you <tt>#ifdef</tt> your work
 properly; also, document your kludge so that people know to remove it
 once the external problems have been fixed.
          <p>
@@ -2840,7 +2856,7 @@ might be just about to upload a fix for the problem, or have a better
 solution present.
        <p>
 NMUs should be made to assist a package's maintainer in resolving bugs.
-Maintainers should be thankfull for that help, and NMUers should respect
+Maintainers should be thankful for that help, and NMUers should respect
 the decisions of maintainers, and try to personally help the maintainer by
 their work.
        <p>
@@ -2859,7 +2875,7 @@ the bug. Don't forget to tag the bug with the "patch" keyword.
            <item>
 Wait a few more days. If you still haven't got an answer from the
 maintainer, send them a mail announcing your intent to NMU the package.
-Prepare an NMU as described in <ref id="nmu-guidelines">, test it
+Prepare an NMU as described in this section, and test it
 carefully on your machine (cf. <ref id="sanitycheck">).
 Double check that your patch doesn't have any unexpected side effects.
 Make sure your patch is as small and as non-disruptive as it can be.  
@@ -2889,7 +2905,7 @@ for a package to enter testing is through unstable.
        <p>
 For the stable distribution, please take extra care. Of course, the release
 managers may also change the rules here. Please verify before upload that
-all your changes are ok for inclusion into the next stable release by the
+all your changes are OK for inclusion into the next stable release by the
 release manager.
        <p>
 When a security bug is detected, the security team may do an NMU, using
@@ -3078,7 +3094,7 @@ distinguish in terminology between porter NMUs and non-porter NMUs.
 Both classes of NMUs, source and binary-only, can be lumped by the
 term ``NMU''.  However, this often leads to confusion, since most
 people think ``source NMU'' when they think ``NMU''.  So it's best to
-be careful. Best use always ``binary NMU'' or ``binNMU'' for binary-only
+be careful: always use ``binary NMU'' or ``binNMU'' for binary-only
 NMUs.
 
 
@@ -3089,7 +3105,7 @@ NMUs.
 package maintenance duties by several people.  This collaboration is
 almost always a good idea, since it generally results in higher quality and
 faster bug fix turnaround time.  It is strongly recommended that
-packages in which a priority of <tt>Standard</tt> or which are part of
+packages with a priority of <tt>Standard</tt> or which are part of
 the base set have co-maintainers.</p>
         <p>
 Generally there is a primary maintainer and one or more
@@ -3149,8 +3165,8 @@ Please see below for details.
 The scripts that update the <em>testing</em> distribution are run each
 day after the installation of the updated packages. They generate the
 <file>Packages</file> files for the <em>testing</em> distribution, but
-they do so in an intelligent manner trying to avoid any inconsistency
-and trying to use only non-buggy packages.
+they do so in an intelligent manner; they try to avoid any inconsistency
+and to use only non-buggy packages.
        <p>
 The inclusion of a package from <em>unstable</em> is conditional on
 the following:
@@ -3158,35 +3174,35 @@ the following:
     <item>
 The package must have been available in <em>unstable</em> for 2, 5 or 10
 days, depending on the urgency (high, medium or low).
-Please note that the urgency is sticky, means that the highest
-urgency uploaded since the last testing transition is taken into account.
-Those delays may be doubled during a freeze, or testing transition may be
-switched off at all;
+Please note that the urgency is sticky, meaning that the highest
+urgency uploaded since the previous testing transition is taken into account.
+Those delays may be doubled during a freeze, or testing transitions may be
+switched off altogether;
     <item>
-It must have less release-critical bugs than the version available
+It must have fewer release-critical bugs than the version currently available
 in <em>testing</em>;
     <item>
-It must be available on all architectures on which it has been
-previously built in unstable. <ref id="madison"> may be of interest to
+It must be available on all architectures on which it has previously
+been built in unstable. <ref id="madison"> may be of interest to
 check that information;
     <item>
-It must not break any dependency of a package that is already available
+It must not break any dependency of a package which is already available
 in <em>testing</em>;
     <item>
 The packages on which it depends must either be available in <em>testing</em>
 or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect all the necessary criteria);
+if they fulfill all the necessary criteria);
 </list>
        <p>
 To find out whether a package is progressing into testing or not, see the
 testing script output on the <url name="web page of the testing distribution"
 id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
 which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep one
-informed of the progression of their packages into <em>testing</em>.
+easily be used in a <manref name="crontab" section="5"> to keep yourself
+informed of the progression of your packages into <em>testing</em>.
        <p>
 The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it on their own by looking
+why the package is refused; you may have to find it on your own by looking
 for what would break with the inclusion of the package. The
 <url id="&url-testing-maint;" name="testing web page"> gives some more
 information about the usual problems which may be causing such troubles.
@@ -3196,15 +3212,17 @@ inter-relationship is too complicated and cannot be sorted out
 by the scripts. See below for details.
        <p>
 Some further dependency analysis is shown on
-<url id="http://bjorn.haxx.se/debian/"> - but be warned, they show also
-the build dependencies that are not considered by britney.
+<url id="http://bjorn.haxx.se/debian/"> &mdash; but be warned,
+this page also shows build dependencies which
+are not considered by britney.
 
        <sect2 id="outdated">
        <heading>out-of-date</heading>
        <p>
+<!-- FIXME: better rename this file than document rampant professionalism? -->
 For the testing migration script, "outdated" means: There are different
 versions in unstable for the release architectures (except for the
-architectures in fuckedarches; fuckedarches is an list of architectures
+architectures in fuckedarches; fuckedarches is a list of architectures
 that don't keep up (in update_out.py), but currently, it's empty).
 "outdated" has nothing whatsoever to do with the architectures this package
 has in testing.
@@ -3243,9 +3261,9 @@ if you maintain glibc or so.)
        <heading>Removals from testing</heading>
        <p>
 Sometimes, a package is removed to allow another package in: This happens
-only to allow _another_ package to go in, that's ready in every other
-sense. Consider e.g. that a conflicts with the new version of b; than a may
-be removed to allow b in.
+only to allow <em>another</em> package to go in if it's ready in every other
+sense. Suppose e.g. that <em>a</em> conflicts with the new version of
+<em>b</em>; then <em>a</em> may be removed to allow <em>b</em> in.
        <p>
 Of course, there is another reason to remove a package from testing: It's
 just too buggy (and having a single RC-bug is enough to be in this state).
@@ -3253,8 +3271,8 @@ just too buggy (and having a single RC-bug is enough to be in this state).
        <sect2 id="circular">
        <heading>circular dependencies</heading>
        <p>
-A situation that is not handled very well by britney is if package a
-depends on the new version of package b, and vice versa.
+A situation which is not handled very well by britney is if package <em>a</em>
+depends on the new version of package <em>b</em>, and vice versa.
        <p>
 An example of this is:
        <p>
@@ -3265,10 +3283,10 @@ a | 1; depends: b=1 |  2; depends: b=2
 b | 1; depends: a=1 |  2; depends: a=2
        </example>
        <p>
-Package a is not considered for update, and package b also not.
+Neither package <em>a</em> nor package <em>b</em> is considered for update.
        <p>
 Currently, this requires some manual hinting from the release team.
-Please, contact them by sending mail to &email-debian-release; if that
+Please contact them by sending mail to &email-debian-release; if this
 happens to one of your packages.
 
 
@@ -3282,7 +3300,7 @@ even if it is still RC-buggy. The second exception is if the version
 of the package in testing is out of sync on the different arches: Then
 any arch might just upgrade to the version of the source package;
 however, this can happen only if the package was previously forced
-through, the arch is in fuckedarches or there was no binary package of that
+through, the arch is in fuckedarches, or there was no binary package of that
 arch present in unstable at all during the testing migration.
        <p>
 In summary this means: The only influence that a package being in testing
@@ -3296,17 +3314,17 @@ If you are interested in details, this is how britney works:
        <p>
 The packages are looked at to determine whether they are valid
 candidates. This gives the "update excuses". The most common reasons
-why a package is not considered are too young, RC-bugginess and out of
+why a package is not considered are too young, RC-bugginess, and out of
 date on some arches. For this part, the release managers have hammers
 of any size to force britney to consider a package. (Also, the base
 freeze is coded in that part of britney.) (There is a similar thing
 for binary-only updates, but this is not described here. If you're
-interessted in that, please use the code.)
+interested in that, please peruse the code.)
        <p>
 Now, the more complex part happens: Britney tries to update testing with
 the valid candidates; first, each package alone, and then larger and even
-larger sets of packages together. Each try is accepted if sarge is not
-more uninstallable after the update as before. (Before and after this part,
+larger sets of packages together. Each try is accepted if unstable is not
+more uninstallable after the update than before. (Before and after this part,
 some hints are processed; but as only release masters can hint, this is
 probably not so important for you.)
        <p>
@@ -3333,28 +3351,31 @@ have to go through the hands of the release manager. So you'd better have a good
 reason to upload there. In order to know what a good reason is in the
 release manager's eyes, you should read the instructions that he regularly
 gives on &email-debian-devel-announce;.
+<!-- FIXME: gender-specific; fix when RM is female at the very latest -->
          <p>
 You should not upload to <em>testing-proposed-updates</em> when you can update your
 packages through <em>unstable</em>. If you can't (for example because you have a
-newer development version in unstable), you may use it but it is recommended to ask
-the authorization of the release manager before. Even if a package is
+newer development version in unstable), you may use this facility,
+but it is recommended that you ask for authorization from
+the release manager first.
+Even if a package is
 frozen, updates through unstable are possible, if the upload via unstable
-does not pulls an new dependency in.
+does not pull in any new dependencies.
          <p>
 Version numbers are usually selected by adding the codename of the testing
-distribution and a incrementing number, like 1.2sarge1 for the first upload
-through testing-proposed-updates of the package version 1.2.
+distribution and a running number, like 1.2sarge1 for the first upload
+through testing-proposed-updates of package version 1.2.
        <p>
-Please make sure you didn't miss any of these items at your upload:
+Please make sure you didn't miss any of these items in your upload:
 <list>
 <item> Make sure that your package really needs to go through
-<em>testing-proposed-uploads</em>, and can't go through unstable;
+<em>testing-proposed-updates</em>, and can't go through unstable;
 <item> Make sure that you included only the minimal amount of changes;
-<item> Make sure that you included an appropriate explaination in the
+<item> Make sure that you included an appropriate explanation in the
 changelog;
 <item> Make sure that you've written <em>testing</em> or
 <em>testing-proposed-updates</em> into your target distribution;
-<item> Make sure that you've build and tested your package in
+<item> Make sure that you've built and tested your package in
 <em>testing</em>, not in <em>unstable</em>;
 <item> Make sure that your version number is higher than the version in
 <em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
@@ -3371,7 +3392,7 @@ release team at &email-debian-release; and ask them to approve your upload.
        <sect2 id="rc">
        <heading>What are release-critical bugs, and how do they get counted?</heading>
          <p>
-All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
+All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave, and serious bugs.
          <p>
 Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
          <p>
@@ -3381,13 +3402,13 @@ The "testing" bug count for a package is considered to be roughly the bug count
        <sect2>
        <heading>How could installing a package into "testing" possibly break other packages?</heading>
          <p>
-The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
+The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
          <p>
 However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
          <p>
-Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties.
+Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
          <p>
-When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care now has to be taken: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
+When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
          <p>
 If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help.
       </sect>
@@ -3432,7 +3453,7 @@ changed.
 Helper scripts take care of these issues.  Assuming you comply with
 the conventions expected by the helper script, the helper takes care
 of all the details.  Changes in policy can be made in the helper
-script, then packages just need to be rebuilt with the new version of
+script; then packages just need to be rebuilt with the new version of
 the helper and no other changes.
        <p>
 <ref id="tools"> contains a couple of different helpers. The most
@@ -3631,7 +3652,7 @@ I as a user need this package?  What other features does the package
 have?  What outstanding features and deficiencies are there compared
 to other packages (e.g., "if you need X, use Y instead")?  Is this
 package related to other packages in some way that is not handled by
-the package manager (e.g., "this is the client to the foo server")?
+the package manager (e.g., "this is the client for the foo server")?
            <p>
 Be careful to avoid spelling and grammar mistakes. Ensure that you
 spell-check it.  <prgn>ispell</prgn> has a special <tt>-g</tt> option
@@ -3639,17 +3660,17 @@ for <file>debian/control</file> files:
 
 <example>ispell -d american -g debian/control</example>
            <p>
-User usually expect these questions to be answered in the package
-description.
+Users usually expect these questions to be answered in the package
+description:
        <list>
        <item>
 What does the package do? If it is an add-on to another package,
-then the short description of the package we are an add on to
+then the short description of the package we are an add-on to
 should be put in here.
        <item>
-Why should I want this package?  This is related  to the above,
+Why should I want this package?  This is related to the above,
 but not the same (this is a mail user agent; this is cool, fast,
-interfaces with pgp and ldap and imap, has features X, Y, and Z).
+interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
        <item>
 If this package should not be installed directly, but is pulled in
 by another package, this should be mentioned.
@@ -3660,7 +3681,7 @@ used instead, it should be here as well.
        <item>
 How is this package different from the competition? Is it a better
 implementation? more features? different features? Why should I
-choose this package (2. should talk about the class of packages, and
+choose this package (the second questions is about the class of packages, and
 this about this particular package, if you have information related to both).
        </list>
 
@@ -3831,7 +3852,7 @@ start by inserting the title of each different bug.
         </sect1>
        
        <sect1 id="bpp-news-debian">
-          <heading>Suplimenting changelogs with NEWS.Debian files</heading>
+          <heading>Supplementing changelogs with NEWS.Debian files</heading>
          <p>
 Important news about changes in a package can also be put in NEWS.Debian
 files. The news will be displayed by tools like apt-listchanges, before
@@ -3855,7 +3876,7 @@ cron (3.0pl1-74) unstable; urgency=low
     functionality provided with that script, please install the new
     package.
 
- -- Steve Greenland &lt;stevegr&amp;debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
+ -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
 </example>
           <p>
 The NEWS.Debian file is installed as
@@ -3904,7 +3925,7 @@ the <file>postinst</file> script.
         <p>
 Keep the maintainer scripts as simple as possible.  We suggest you use
 pure POSIX shell scripts.  Remember, if you do need any bash features,
-the maintainer script must have a bash sh-bang line.  POSIX shell or
+the maintainer script must have a bash shebang line.  POSIX shell or
 Bash are preferred to Perl, since they enable
 <package>debhelper</package> to easily add bits to the scripts.
         <p>
@@ -3917,7 +3938,7 @@ If you need to check for the existence of a command, you should use
 something like
 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
 
-If you don't wish to hard-code the path of the command in your
+If you don't wish to hard-code the path of a command in your
 maintainer script, the following POSIX-compliant shell function may
 help:
 
@@ -4012,7 +4033,7 @@ If you maintain XML or SGML documentation, we suggest that you isolate
 any language-independent information and define those as entities in a
 separate file which is included by all the different
 translations. This makes it much easier, for instance, to keep URLs
-up-to-date across multiple files.
+up to date across multiple files.
         </sect1>
       </sect>
 
@@ -4031,7 +4052,7 @@ up-to-date across multiple files.
           <prgn>autoconf</prgn>/<prgn>automake</prgn></heading>
           <p>
 Keeping <prgn>autoconf</prgn>'s <file>config.sub</file> and
-<file>config.guess</file> files up-to-date is critical for porters,
+<file>config.guess</file> files up to date is critical for porters,
 especially on more volatile architectures.  Some very good packaging
 practices for any package using <prgn>autoconf</prgn> and/or
 <prgn>automake</prgn> have been synthesized in
@@ -4045,7 +4066,7 @@ to follow the given recommendations.
 Libraries are always difficult to package for various reasons. The policy
 imposes many constraints to ease their maintenance and to make sure
 upgrades are as simple as possible when a new upstream version comes out.
-A breakage in a library can result in dozens of dependent packages
+Breakage in a library can result in dozens of dependent packages
 breaking.
        <p>
 Good practices for library packaging have been grouped in
@@ -4105,6 +4126,7 @@ package.
 Lisp packages should register themselves with
 <package>common-lisp-controller</package>, about which see
 &file-lisp-controller;.
+<!-- TODO: mozilla extension policy, once that becomes available -->
 </list>
         </sect1>
 
@@ -4170,19 +4192,19 @@ LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
        <sect1 id="bpp-transition">
           <heading>Make transition packages deborphan compliant</heading>
           <p>
-Deborphan is a program helping users to detect which packages can be safely
+Deborphan is a program for helping users to detect which packages can safely be
 removed from the system, i.e. the ones that have no packages depending on
 them. The default operation is to search only within the libs and oldlibs
 sections, to hunt down unused libraries. But when passed the right argument,
 it tries to catch other useless packages. 
           <p>
-For example, with --guess-dummy, tries to search all transitional packages
+For example, with --guess-dummy, deborphan tries to search all transitional packages
 which were needed for upgrade but which can now safely be removed. For that,
 it looks for the string "dummy" or "transitional" in their short
 description.
           <p>
 So, when you are creating such a package, please make sure to add this text
-to your short description. If you are looking for example, just run: 
+to your short description. If you are looking for examples, just run: 
   <example>apt-cache search .|grep dummy</example> or
   <example>apt-cache search .|grep transitional</example>.
         </sect1>
@@ -4230,7 +4252,7 @@ provide you with this information (and <prgn>reportbug</prgn>
 will usually invoke <prgn>querybts</prgn> before sending, too).
        <p>
 Try to direct your bugs to the proper location. When for example
-your bug is about a package that overwrites files from another package,
+your bug is about a package which overwrites files from another package,
 check the bug lists for <em>both</em> of those packages in order to
 avoid filing duplicate bug reports.
        <p>
@@ -4280,7 +4302,7 @@ possible, and as lintian-clean (see <ref id="lintian">) as
 possible. If you do not find that possible, then you should consider
 orphaning some of your packages (see <ref
 id="orphaning">). Alternatively, you may ask the help of other people
-in order to catch up the backlog of bugs that you have (you can ask
+in order to catch up with the backlog of bugs that you have (you can ask
 for help on &email-debian-qa; or &email-debian-devel;). At the same
 time, you can look for co-maintainers (see <ref id="collaborative-maint">).
        
@@ -4288,13 +4310,13 @@ time, you can look for co-maintainers (see <ref id="collaborative-maint">).
        <p>
 From time to time the QA group organizes bug squashing parties to get rid of
 as many problems as possible. They are announced on &email-debian-devel-announce;
-and the announce explains what area will be focused on during the party:
+and the announcement explains which area will be the focus of the party:
 usually they focus on release critical bugs but it may happen that they
-decide to help finish a major upgrade going on (like a new perl version
+decide to help finish a major upgrade (like a new perl version
 which requires recompilation of all the binary modules).
        <p>
 The rules for non-maintainer uploads differ during the parties because
-the announce of the party is considered like a prior notice for NMU. If
+the announcement of the party is considered prior notice for NMU. If
 you have packages that may be affected by the party (because they have
 release critical bugs for example), you should send an update to each of
 the corresponding bug to explain their current status and what you expect
@@ -4304,12 +4326,12 @@ the BTS.
        <p>
 People participating in the party have special rules for NMU, they can
 NMU without prior notice if they upload their NMU to
-DELAYED/3-day at least. All other NMU rules applies as usually, they
-should send the patch of the NMU in the BTS (in one of the open bugs
-fixed by the NMU or in a new bug tagged fixed). They should
-also respect the maintainer's wishes if he expressed some.
+DELAYED/3-day at least. All other NMU rules apply as usually; they
+should send the patch of the NMU to the BTS (to one of the open bugs
+fixed by the NMU, or to a new bug, tagged fixed). They should
+also respect any particular wishes of the maintainer.
        <p>
-If someone doesn't feel confident with an NMU, he should just send a patch
+If you don't feel confident about doing an NMU, just send a patch
 to the BTS. It's far better than a broken NMU.
 
 
@@ -4332,7 +4354,7 @@ You may also be interested in contacting the persons who are
 subscribed to a given source package via <ref id="pkg-tracking-system">.
 You can do so by using the <tt>&lt;package-name&gt;@&pts-host;</tt>
 email address.
-
+<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
 
     <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers
       <p>
@@ -4343,9 +4365,9 @@ haven't registered out of the system, so to speak. On the other hand,
 it is also possible that they just need a reminder.
       <p>
 There is a simple system (the MIA database) in which information about
-maintainers who are deemed inactive are recorded.  When a member of the
+maintainers who are deemed Missing In Action are recorded.  When a member of the
 QA group contacts an inactive maintainer or finds more information about
-them, this is recorded in the MIA database.  This system is available
+one, this is recorded in the MIA database.  This system is available
 in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried
 with a tool known as <prgn>mia-history</prgn>.  By default,
 <prgn>mia-history</prgn> shows information about every person it knows
@@ -4353,12 +4375,12 @@ about, but it accepts regular expressions as arguments which it uses to
 match user names.  <example>mia-history --help</example> shows which
 arguments are accepted.  If you find that no information has been recorded
 about an inactive maintainer already, or that you can add more information,
-you will generally proceed as follows.
+you should generally proceed as follows.
       <p>
 The first step is to politely contact the maintainer, and wait for a
-response, for a reasonable time. It is quite hard to define "reasonable
+response for a reasonable time. It is quite hard to define "reasonable
 time", but it is important to take into account that real life is sometimes
-very hectic. One way to handle this would be send a reminder after two
+very hectic. One way to handle this would be to send a reminder after two
 weeks.
       <p>
 If the maintainer doesn't reply within four weeks (a month), one can
@@ -4369,7 +4391,7 @@ about the maintainer in question as possible. This includes:
       <list>
        <item>The "echelon" information available through the 
               <url id="&url-debian-db;" name="developers' LDAP database">,
-              which indicates when's the last time a developer has posted to
+              which indicates when the developer last has posted to
               a Debian mailing list. (This includes uploads via
               debian-*-changes lists.) Also, remember to check whether the
               maintainer is marked as "on vacation" in the database.
@@ -4379,7 +4401,7 @@ about the maintainer in question as possible. This includes:
               any RC bugs that have been open for ages? Furthermore, how
               many bugs are there in general? Another important piece of
               information is whether the packages have been NMUed, and if
-              so, by whom?
+              so, by whom.
 
        <item>Is there any activity of the maintainer outside of Debian? 
               For example, they might have posted something recently to
@@ -4407,7 +4429,7 @@ One last word: please remember to be polite. We are all volunteers and
 cannot dedicate all of our time to Debian. Also, you are not aware of the
 circumstances of the person who is involved. Perhaps they might be
 seriously ill or might even had died &mdash; you do not know who may be on the
-receiving side &mdash; imagine how a relative will feel if they read the e-mail
+receiving side. Imagine how a relative will feel if they read the e-mail
 of the deceased and find a very impolite, angry and accusing message!)
       <p>
 On the other hand, although we are volunteers, we do have a responsibility. 
@@ -4457,7 +4479,7 @@ By uploading a sponsored package to Debian, you are certifying that
 the package meets minimum Debian standards.  That implies that you
 must build and test the package on your own system before uploading.
        <p>
-You can not simply upload a binary <file>.deb</file> from the sponsoree. In
+You cannot simply upload a binary <file>.deb</file> from the sponsoree. In
 theory, you should only ask for the diff file and the location of the
 original source tarball, and then you should download the source and apply
 the diff yourself. In practice, you may want to use the source package
@@ -4473,7 +4495,7 @@ means being a mentor.
 Once the package meets Debian standards, build and sign it with                           
 <example>dpkg-buildpackage -k<var>KEY-ID</var></example>                                  
 before uploading it to the incoming directory. Of course, you can also
-use any part of your <var>KEY-ID</var>, as long as it's uniq in your
+use any part of your <var>KEY-ID</var>, as long as it's unique in your
 secret keyring.
        <p>
 The Maintainer field of the <file>control</file> file and the
@@ -4502,10 +4524,10 @@ Application Managers"> at the Debian web site.
     and being translated
       <p>
 Debian supports an ever-increasing number of natural languages. Even if you are
-native English speaker and do not speak any other language, it is part of your
+native English speaker and do not speak any other language, it is part of your
 duty as a maintainer to be aware of issues of internationalization (abbreviated
 i18n because there are 18 letters between the 'i' and the 'n' in
-internationalization). Therefore, even if you are ok with English only
+internationalization). Therefore, even if you are ok with English-only
 programs, you should read most of this chapter.
       <p>
 According to <url id="http://www.debian.org/doc/manuals/intro-i18n/"
@@ -4515,16 +4537,16 @@ potentially handle multiple languages, customs, and so on in the world." while
 "L10N (localization) means implementation of a specific language for an already
 internationalized software."
       <p>
-l10n and i18n are tied, but the difficulties related to each of them are very
+l10n and i18n are interconnected, but the difficulties related to each of them are very
 different. It's not really difficult to allow a program to change the language
 in which texts are displayed based on user settings, but it is very time
 consuming to actually translate these messages. On the other hand, setting the
 character encoding is trivial, but adapting the code to use several character
 encodings is a really hard problem.
       <p>
-Letting alone the i18n problems, where no general receipt exist, there is
+Setting aside the i18n problems, where no general guideline can be given, there is
 actually no central infrastructure for l10n within Debian which could be
-compared to the dbuild mechanism for porting. So, most of the work has to be
+compared to the dbuild mechanism for porting. So most of the work has to be
 done manually.
 
 
@@ -4541,104 +4563,110 @@ translation Project"> or the <url id="http://i18n.kde.org/" name="KDE one">.
 The only centralized resource within Debian is the <url
 id="http://www.debian.org/intl/l10n/" name="Central Debian translation
 statistics">, where you can find some statistics about the translation files
-found in the actual package, but no real infrastructure to ease the translation
+found in the actual packages, but no real infrastructure to ease the translation
 process.
          <p>
-An effort to translate the package descriptions started long ago even if very
-few support is offered by the tools to actually use them (ie, only APT can use
-them, when configured correctly). There is nothing to do for the maintainers,
-and the translators should use the <url id="http://ddtp.debian.org/"
+An effort to translate the package descriptions started long ago, even if very
+little support is offered by the tools to actually use them (i.e., only APT can use
+them, when configured correctly). Maintainers don't need to do
+anything special to support translated package descriptions;
+translators should use the <url id="http://ddtp.debian.org/"
 name="DDTP">.
          <p>
-For debconf templates, maintainer should use the po-debconf package to ease the
-work of translators, which could use the DDTP to do their work (but French and
+For debconf templates, maintainers should use the po-debconf package to ease the
+work of translators, who could use the DDTP to do their work (but the French and
 Brazilian teams don't). Some statistics can be found both on the DDTP site
 (about what is actually translated), and on the <url
 id="http://www.debian.org/intl/l10n/" name="Central Debian translation
 statistics"> site (about what is integrated in the packages). 
-         p>
+         <p>
 For web pages, each l10n team has access to the relevant CVS, and the statistics
 are available from the Central Debian translation statistics site.
          <p>
 For general documentation about Debian, the process is more or less the same
-than for the web pages (the translators have an access to the CVS), but there is
+than for the web pages (the translators have access to the CVS), but there are
 no statistics pages.
          <p>
-For package specific documentation (man pages, info document, other formats),
-almost everything have yet to be done. Most notably, the KDE project handles
+For package-specific documentation (man pages, info documents, other formats),
+almost everything remains to be done.
+       <p>
+Most notably, the KDE project handles
 translation of its documentation in the same way as its program messages.
-Debian specific man pages begin to be handled within a <url
+       <p>
+There is an effort to handle Debian-specific man pages
+within a <url
 id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="specific CVS
-repository"> .
+repository">.
 
 
        <sect id="l10n-faqm">I18N &amp; L10N FAQ for maintainers
          <p>
 This is a list of problems that maintainers may face concerning i18n and l10n.
-While reading this, keep in mind that there is no real consensus on those
-points within Debian, and that they are only advices. If you have a better idea
+While reading this, keep in mind that there is no real consensus on these
+points within Debian, and that this is only advice. If you have a better idea
 for a given problem, or if you disagree on some points, feel free to provide
 your feedback, so that this document can be enhanced.
 
-         <sect1 id="l10n-faqm-tr">How to get a given text translated?
+         <sect1 id="l10n-faqm-tr">How to get a given text translated
            <p>
-To translate package description or debconf templates, you have nothing to do,
+To translate package descriptions or debconf templates, you have nothing to do;
 the DDTP infrastructure will dispatch the material to translate to volunteers
 with no need for interaction from your part.
            <p>
-For all other material (gettext files, man pages or other documentation), the
-best solution is to put your text somewhere on Internet, and ask on debian-i18n
-for a translation in the different languages. Some translation team members are
+For all other material (gettext files, man pages, or other documentation), the
+best solution is to put your text somewhere on the Internet, and ask on debian-i18n
+for a translation in different languages. Some translation team members are
 subscribed to this list, and they will take care of the translation and of the
-reviewing process. Once done, you will get your translated document from them
+reviewing process. Once they are done, you will get your translated document from them
 in your mailbox.
 
-         <sect1 id="l10n-faqm-rev">How to get a given translation reviewed?
+         <sect1 id="l10n-faqm-rev">How to get a given translation reviewed
            <p>
->From time to time, individuals translate some texts included in your package
-and will ask you for inclusion in the package. This can become problematic if
+From time to time, individuals translate some texts in your package
+and will ask you for inclusion of the translation in the package. This can become problematic if
 you are not fluent in the given language. It is a good idea to send the
 document to the corresponding l10n mailing list, asking for a review. Once it
 has been done, you should feel more confident in the quality of the
-translation, and include it fearlessly into your package.
+translation, and feel safe to include it in your package.
 
-         <sect1 id="l10n-faqm-update">How to get a given translation updated?
+         <sect1 id="l10n-faqm-update">How to get a given translation updated
            <p>
-If you have some translations of a given text laying around, each time you
-update the original, you should kindly ask to the previous translator to update
-his/her work to make the translation up to date with regard to the current
-original text. Keep in mind that this task takes time, at least one week to get
+If you have some translations of a given text lying around, each time you
+update the original, you should ask the previous translator to update
+the translation with your new changes.
+Keep in mind that this task takes time; at least one week to get
 the update reviewed and all. 
            <p>
-If the translator is unresponsive, you may ask for help to the corresponding
+If the translator is unresponsive, you may ask for help on the corresponding
 l10n mailing list. If everything fails, don't forget to put a warning in the
 translated document, stating that the translation is somehow outdated, and that
 the reader should refer to the original document if possible. 
            <p>
-Avoid removing completely a translation because it is outdated. An old
+Avoid removing a translation completely because it is outdated. Old
 documentation is often better than no documentation at all for non-English
-speaker.
+speakers.
 
-         <sect1 id="l10n-faqm-bug">How to handle a bug report concerning a translation?
+         <sect1 id="l10n-faqm-bug">How to handle a bug report concerning a translation
            <p>
 The best solution may be to mark the bug as "forwarded to upstream", and
 forward it to both the previous translator and his/her team (using the
 corresponding debian-l10n-XXX mailing list).
+<!-- TODO: add the i18n tag to the bug? -->
 
        <sect id="l10n-faqtr">I18N &amp; L10N FAQ for translators
          <p>
 While reading this, please keep in mind that there is no general procedure
-within Debian concerning those points, and that in any case, you should
+within Debian concerning these points, and that in any case, you should
 collaborate with your team and the package maintainer.
 
-         <sect1 id="l10n-faqtr-help">How to help the translation effort?
+         <sect1 id="l10n-faqtr-help">How to help the translation effort
            <p>
 Choose what you want to translate, make sure that nobody is already working on
 it (using your debian-l10n-XXX mailing list), translate it, get it reviewed by
 other native speakers on your l10n mailing list, and provide it to the
 maintainer of the package (see next point).
 
-         <sect1 id="l10n-faqtr-inc">How to provide a translation for inclusion in a package?
+         <sect1 id="l10n-faqtr-inc">How to provide a translation for inclusion in a package
            <p>
 Make sure your translation is correct (asking for review on your l10n mailing
 list) before providing it for inclusion. It will save time for everyone, and
@@ -4646,7 +4674,7 @@ avoid the chaos resulting in having several versions of the same document in
 bug reports.
            <p>
 The best solution is to fill a regular bug containing the translation against
-the package. Make sure to use the 'PATCH' tag, and to not use a gravity higher
+the package. Make sure to use the 'PATCH' tag, and to not use a severity higher
 than 'wishlist', since the lack of translation never prevented a program from
 running.
 
@@ -4665,7 +4693,7 @@ they don't report the errors they find, nobody will.
     <item>
 In any case, remember that the major issue with l10n is that it requires
 several people to cooperate, and that it is very easy to start a flamewar about
-small problems because of misunderstanding. So, if you have problems with your
+small problems because of misunderstandings. So if you have problems with your
 interlocutor, ask for help on the corresponding l10n mailing list, on
 debian-i18n, or even on debian-devel (but beware, l10n discussions very often
 become flamewars on that list :)
@@ -4680,7 +4708,7 @@ This section contains a rough overview of the tools available to
 maintainers.  The following is by no means complete or definitive, but
 just a guide to some of the more popular tools.
       <p>
-Debian maintainer tools are meant to help convenience developers and 
+Debian maintainer tools are meant to aid developers and 
 free their time for critical tasks.  As Larry Wall says, there's more
 than one way to do it.
       <p>
@@ -4688,7 +4716,7 @@ Some people prefer to use high-level package maintenance tools and
 some do not.  Debian is officially agnostic on this issue; any tool
 which gets the job done is fine.  Therefore, this section is not meant
 to stipulate to anyone which tools they should use or how they should
-go about with their duties of maintainership.  Nor is it meant to
+go about their duties of maintainership.  Nor is it meant to
 endorse any particular tool to the exclusion of a competing tool.
       <p>
 Most of the descriptions of these packages come from the actual
@@ -4705,10 +4733,10 @@ The following tools are pretty much required for any maintainer.</p>
        <heading><package>dpkg-dev</package>
        <p>
 <package>dpkg-dev</package> contains the tools (including
-<prgn>dpkg-source</prgn>) required to unpack, build and upload Debian
+<prgn>dpkg-source</prgn>) required to unpack, build, and upload Debian
 source packages.  These utilities contain the fundamental, low-level
-functionality required to create and manipulated packages; as such,
-they are required for any Debian maintainer.
+functionality required to create and manipulate packages; as such,
+they are essential for any Debian maintainer.
 
       <sect1 id="debconf">
         <heading><package>debconf</package></heading>
@@ -4717,12 +4745,12 @@ they are required for any Debian maintainer.
 configuring packages interactively.  It is user interface
 independent, allowing end-users to configure packages with a
 text-only interface, an HTML interface, or a dialog interface.  New
-interfaces can be added modularly.
+interfaces can be added as modules.
         <p>
 You can find documentation for this package in the
 <package>debconf-doc</package> package.
         <p>
-Many feel that this system should be used for all packages requiring
+Many feel that this system should be used for all packages which require
 interactive configuration; see <ref id="bpp-config-mgmt">.
 <package>debconf</package> is not currently required by Debian Policy,
 but that may change in the future.
@@ -4735,7 +4763,7 @@ but that may change in the future.
 you to build packages without being root (packages usually want to
 install files with root ownership).  If you have
 <package>fakeroot</package> installed, you can build packages as a
-user: <tt>dpkg-buildpackage -rfakeroot</tt>.
+regular user: <tt>dpkg-buildpackage -rfakeroot</tt>.
         </sect1>
       </sect>
 
@@ -4746,27 +4774,27 @@ According to the Free On-line Dictionary of Computing (FOLDOC), `lint'
 is "a Unix C language processor which carries out more thorough checks
 on the code than is usual with C compilers."  Package lint tools help
 package maintainers by automatically finding common problems and
-policy violations with their packages.</p>
+policy violations in their packages.</p>
 
         <sect1 id="lintian">
           <heading><package>lintian</package></heading>
           <p>
 <package>lintian</package> dissects Debian packages and emits
-information on bugs
+information about bugs
 and policy violations. It contains automated checks for many aspects
 of Debian policy as well as some checks for common errors.
        <p>
 You should periodically get the newest <package>lintian</package> from
 `unstable' and check over all your packages. Notice that the <tt>-i</tt>
 option provides detailed explanations of what each error or warning means,
-what is its basis in Policy, and commonly how you can fix the problem.
+what its basis in Policy is, and commonly how you can fix the problem.
        <p>
 Refer to <ref id="sanitycheck"> for more information on how and when
 to use Lintian.
        <p>
 You can also see a summary of all problems reported by Lintian on your
-packages at <url id="&url-lintian;">. Those reports contain the latest
-<prgn>lintian</prgn> output on the whole development distribution
+packages at <url id="&url-lintian;">. These reports contain the latest
+<prgn>lintian</prgn> output for the whole development distribution
 ("unstable").
         </sect1>
 
@@ -4784,7 +4812,7 @@ written in Python rather than Perl.</p>
 <prgn>debdiff</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">)
 compares file lists and control files of two packages. It is a simple
 regression test, as it will help you notice if the number of binary
-packages has changed since the last upload, or if something's changed
+packages has changed since the last upload, or if something has changed
 in the control file. Of course, some of the changes it reports will be
 all right, but it can help you prevent various accidents.
          <p>
@@ -4809,20 +4837,21 @@ For more information please see <manref name="debdiff" section="1">.
        <p>
 Package building tools make the process of writing
 <file>debian/rules</file> files easier.  See <ref id="helper-scripts">
-for more information on why these might or might not be desired.
+for more information about why these might or might not be desired.
 
         <sect1 id="debhelper">
           <heading><package>debhelper</package></heading>
        <p>
-<package>debhelper</package> is a collection of programs that can be
+<package>debhelper</package> is a collection of programs which can be
 used in <file>debian/rules</file> to automate common tasks related to
-building binary Debian packages. Programs are included to install
+building binary Debian packages. <package>debhelper</package> includes
+programs to install
 various files into your package, compress files, fix file permissions,
-integrate your package with the Debian menu system.
+and integrate your package with the Debian menu system.
        <p>
 Unlike some approaches, <package>debhelper</package> is broken into
-several small, granular commands which act in a consistent manner.  As
-such, it allows a greater granularity of control than some of the
+several small, simple commands which act in a consistent manner.  As
+such, it allows more fine-grained control than some of the
 other "debian/rules tools".
        <p>
 There are a number of little <package>debhelper</package> add-on
@@ -4833,8 +4862,8 @@ them by doing <tt>apt-cache search ^dh-</tt>.
         <sect1 id="debmake">
           <heading><package>debmake</package>
        <p>
-<package>debmake</package>, a pre-cursor to
-<package>debhelper</package>, is a less granular
+<package>debmake</package>, a precursor to
+<package>debhelper</package>, is a more coarse-grained
 <file>debian/rules</file> assistant. It includes two main programs:
 <prgn>deb-make</prgn>, which can be used to help a maintainer convert
 a regular (non-Debian) source archive into a Debian source package;
@@ -4917,14 +4946,14 @@ a version control system.
           <heading><package>debootstrap</package></heading>
           <p>
 The <package>debootstrap</package> package and script allows you to
-"bootstrap" a Debian base system into any part of your file-system.
+"bootstrap" a Debian base system into any part of your filesystem.
 By "base system", we mean the bare minimum of packages required to
 operate and install the rest of the system.
        <p>
 Having a system like this can be useful in many ways. For instance,
 you can <prgn>chroot</prgn> into it if you want to test your build
-depends.  Or, you can test how your package behaves when installed
-into a bare base system.  Chroot builders use this package, see below.
+dependencies.  Or you can test how your package behaves when installed
+into a bare base system.  Chroot builders use this package; see below.
         </sect1>
 
         <sect1 id="pbuilder">
@@ -4936,7 +4965,7 @@ build-dependencies are correct, and to be sure that unnecessary and
 wrong build dependencies will not exist in the resulting package.</p>
           <p>
 A related package is <package>pbuilder-uml</package>, which goes even
-further build doing the build within User-mode-linux.</p>
+further by doing the build within a User Mode Linux environment.</p>
         </sect1>
 
       <sect1 id="sbuild">
@@ -4989,8 +5018,8 @@ helps in removing files from the ftp upload directory.
         <heading>Maintenance automation</heading>
         <p>
 The following tools help automate different maintenance tasks, from
-adding changelog entries or signature lines, looking up bugs in Emacs,
-to making use of the newest and official use of
+adding changelog entries or signature lines and looking up bugs in Emacs
+to making use of the newest and official
 <file>config.sub</file>.</p>
 
         <sect1 id="devscripts">
@@ -5004,7 +5033,7 @@ file from the command-line, and <prgn>debuild</prgn>, which is a
 wrapper around <prgn>dpkg-buildpackage</prgn>. The <prgn>bts</prgn>
 utility is also very helpful to update the state of bug reports on the
 command line.  <prgn>uscan</prgn> can be used to watch for new upstream
-versions of your packages.  The <prgn>debrsign</prgn> can be used to
+versions of your packages.  <prgn>debrsign</prgn> can be used to
 remotely sign a package prior to upload, which is nice when the
 machine you build the package on is different from where your GPG keys
 are.</p>
@@ -5016,7 +5045,8 @@ complete list of available scripts.</p>
         <sect1 id="autotools-dev">
           <heading><package>autotools-dev</package></heading>
           <p>
-Contains best practices for people maintaining packages that use
+<package>autotools-dev</package>
+contains best practices for people who maintain packages which use
 <prgn>autoconf</prgn> and/or <prgn>automake</prgn>.  Also contains
 canonical <file>config.sub</file> and <file>config.guess</file> files
 which are known to work on all Debian ports.</p>
@@ -5031,8 +5061,8 @@ package while it was unpacked (e.g., files in <file>/etc</file> were
 modified), the new package will inherit the changes.</p>
           <p>
 This utility can make it easy to copy packages from one computer to
-another, or to recreate packages that are installed on your system
-but no longer available elsewhere, or to store the current state of a
+another, or to recreate packages which are installed on your system
+but no longer available elsewhere, or to save the current state of a
 package before you upgrade it.</p>
         </sect1>
 
@@ -5041,7 +5071,7 @@ package before you upgrade it.</p>
           <p>
 <prgn>alien</prgn> converts binary packages between various packaging
 formats, including Debian, RPM (RedHat), LSB (Linux Standard Base),
-Solaris and Slackware packages.</p>
+Solaris, and Slackware packages.</p>
         </sect1>
 
         <sect1 id="debsums">
@@ -5057,9 +5087,11 @@ by Policy.</p>
           <p>
 <package>dpkg-dev-el</package> is an Emacs lisp package which provides
 assistance when editing some of the files in the <file>debian</file>
-directory of your package.  For instance, when editing
-<file>debian/changelog</file>, there are handy functions for
-finalizing a version and listing the package's current bugs.</p>
+directory of your package.  For instance,
+there are handy functions for
+listing a package's current bugs,
+and for finalizing the latest entry in a
+<file>debian/changelog</file> file.
         </sect1>
 
         <sect1 id="dpkg-depcheck">