s/ppc/powerpc/, other spellfixes

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

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 7a6bf65ec14096de1a6856392b8ea84fecf9265c..7169bf87a61bf5bbdaecd1eb0e89dc0788f703fe 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -499,20 +499,20 @@ i386 (or greater) platforms, and so was Debian. But when Linux became
 more and more popular, the kernel was ported to other architectures,
 too.
        <p>
-The Linux 2.0 kernel supports Intel x86, DEC Alpha, Sparc, M68000
-machines (like Atari and Amiga), MIPS, and PowerPC.  Newer kernels
+The Linux 2.0 kernel supports Intel x86, DEC Alpha, Sparc, Motorola 680x0
+machines (like Atari, Amiga and Macintoshes), MIPS, and PowerPC.  Newer kernels
 support more architectures, including ARM, UltraSparc, and MIPS.
 Since Linux supports these platforms, Debian decided that it should,
 too.  Therefore, Debian has ports underway.  Aside from <em>i386</em>
 (our name for Intel x86), there is <em>m68k</em>, <em>alpha</em>,
-<em>ppc</em>, <em>sparc</em>, <em>hurd-i386</em>, and <em>arm</em> as
+<em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>, and <em>arm</em> as
 of this writing.
 
        <p>
 Debian GNU/Linux 1.3 is only available as <em>i386</em>.  Debian 2.0
 supports <em>i386</em> and <em>m68k</em> architectures.  The next
 version of Debian is likely to support <em>i386</em>, <em>m68k</em>,
-<em>alpha</em>, and possibly <em>ppc</em> and <em>sparc</em>
+<em>alpha</em>, and possibly <em>powerpc</em> and <em>sparc</em>
 architectures.
 
 
@@ -1185,10 +1185,10 @@ see <ref id="porter-guidelines">.
 First and foremost, it is critical that NMU patches to source should
 be as non-disruptive as possible.  Do not do housekeeping task, change
 the name of modules, move directories, or fix things which are not
-broken.  Keep the patch as small as possible.  If thing bother you
+broken.  Keep the patch as small as possible.  If things bother you
 aesthetically, talk to the Debian maintainer, talk to the upstream
 maintainer, or submit a bug.  However, aesthetic changes must <em/not/
-be made by non-maintainers.
+be made in a non-maintainer upload.
 
 
        <sect1 id="nmu-version">Source NMU version numbering
@@ -1250,7 +1250,7 @@ By convention, source NMU changelog entries start with the line
 Maintainers other than the official package maintainer should make as
 few changes to the package as possible, and they should always send a
 patch as a unified context diff (<tt/diff -u/) detailing their
-changes, if any, to the Bug Tracking System.
+changes to the Bug Tracking System.
          <p>
 What if you are simply recompiling the package?  In this case, the
 process is different for porters than it is for non-porters, as
@@ -1260,21 +1260,23 @@ to be linked against, a bug was fixed in <package/debhelper/), there
 must still be a changelog entry; therefore, there will be a patch.  If
 you are a porter, you are probably just doing a binary NMU.  (Note:
 this leaves out in the cold porters who have to do recompiles -- chalk
-it up as a weakness in how we maintainer our archive.)
+it up as a weakness in how we maintain our archive.)
          <p>
-If the sounce NMU (non-maintainer upload) fixes some existing bugs,
+If the source NMU (non-maintainer upload) fixes some existing bugs,
 the bugs in the Bug Tracking System which are fixed need to be
 <em/notified/ but not actually <em/closed/ by the non-maintainer.
 Technically, only the official package maintainer or the original bug
 submitter are allowed to close bugs.  However, the person making the
-non-maintainer release must send a short message, including the patch
-for that NMU, to the relevant bugs explaining that the bugs have been
+non-maintainer release must send a short message to the relevant bugs 
+explaining that the bugs have been
 fixed by the NMU.  Using <email/control@bugs.debian.org/, the party
 doing the NMU should also set the severity of the bugs fixed in the
 NMU to `fixed'.  This ensures that everyone knows that the bug was
 fixed in an NMU; however the bug is left open until the changes in the
 NMU are incorporated officially into the package by the official
-package maintainer.
+package maintainer.  Also, open a bug with the patches needed to 
+fix the problem, or make sure that one of the other (already open) bugs
+has the patches.
          <p>
 The normal maintainer will either apply the patch or employ an
 alternate method of fixing the problem.  Sometimes bugs are fixed