Bug#338660: developers-reference: Various typos, forgotten words, and slight rewordings
Package: developers-reference
Version: 3.3.6
Severity: minor
Tags: patch
Hi,
upon reading the Developer's Reference I noticed a few typos and
forgotten words. I append a patch, which fixes those. It also contains
suggestions to improve the wording of few sentences.
uLI
--- /tmp/ediff7676ZEL 2005-11-11 20:26:39.344994822 +0100
+++ /tmp/developers-reference.sgml 2005-11-11 20:26:39.349994237 +0100
@@ -165,7 +165,7 @@
sponsor can request one at <url id="&url-sponsors;">.
-->
Please read the
-inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
+unofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
<p>
If you wish to be a mentor and/or sponsor, more information is
available in <ref id="newmaint">.
@@ -561,7 +561,7 @@
all the files.
<p>
There are other additional channels dedicated to specific subjects.
-<em>#debian-bugs</em> is used for coordinating bug squash parties.
+<em>#debian-bugs</em> is used for coordinating bug squashing parties.
<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
<em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
@@ -2087,9 +2087,9 @@
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
-As bugs and problems are fixed your packages, it is your
-responsibility as the package maintainer to close the bug. However,
-you should not close the bug until the package which fixes the bug has
+As bugs and problems are fixed in your packages, it is your
+responsibility as the package maintainer to close these bugs. However,
+you should not close a bug until the package which fixes the bug has
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
@@ -2849,7 +2849,7 @@
<p>
Some packages still have issues with building and/or working on some
of the architectures supported by Debian, and cannot be ported at all,
-or not with a reasonable amount of time. An example is a package that
+or not within a reasonable amount of time. An example is a package that
is SVGA-specific (only i386), or uses other hardware-specific features
not supported on all architectures.
<p>
@@ -2889,7 +2889,7 @@
A porter or any other person trying to build your package might
accidently upload it without noticing it doesn't work.
If in the past some binary packages were uploaded on unsupported architectures,
-request there removal by filing a bug against
+request their removal by filing a bug against
<package>ftp.debian.org</package>
@@ -2921,9 +2921,10 @@
However, aesthetic changes must <em>not</em> be made in a non-maintainer
upload.
<p>
-And please remember the Hippocratic Oath: "Above all, do no harm."
-It is better if a package has an grave bug open, than if a not working
-patch was applied, and the bug is only hidden now but not resolved.
+And please remember the Hippocratic Oath: "Above all, do no harm." It
+is better to leave a package with an open grave bug than applying a
+non-functional patch, or one that hides the bug instead of resolving
+it.
<sect1 id="nmu-guidelines">How to do a NMU
@@ -2983,7 +2984,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
+managers may also change the rules here. Please verify before you upload that
all your changes are OK for inclusion into the next stable release by the
release manager.
<p>
@@ -3540,7 +3541,7 @@
<sect1 id="helper-scripts">Helper scripts
<p>
The rationale for using helper scripts in <file>debian/rules</file> is
-that lets maintainers use and share common logic among many packages.
+that they let maintainers use and share common logic among many packages.
Take for instance the question of installing menu entries: you need to
put the file into <file>/usr/lib/menu</file>, and add commands to the
maintainer scripts to register and unregister the menu entries. Since
@@ -4079,8 +4080,8 @@
<p>
These guidelines include some writing style and typography
recommendations, general considerations about debconf usage as well as
-more specific recommendations for some parts of the distribution (for
-instance, the installation system).
+more specific recommendations for some parts of the distribution (the
+installation system for instance).
<sect1>Do not abuse debconf
<p>
@@ -4283,7 +4284,7 @@
<sect2>Description: short and extended description
<p>
-Templates descriptions have two parts: short and extended. The short
+Template descriptions have two parts: short and extended. The short
description is in the "Description:" line of the template.
<p>
The short description should be kept short (50 characters or so) so
@@ -4566,7 +4567,7 @@
<p>
Policy specifies that documentation should be shipped in HTML format.
We also recommend shipping documentation in PDF and plain text format if
-convenient and quality output is possible. However, it is generally
+convenient and if output of reasonable quality is possible. However, it is generally
not appropriate to ship plain text versions of documentation whose source
format is HTML.</p>
<p>
@@ -4705,7 +4706,7 @@
distributed by the upstream author.
<footnote>
We cannot prevent upstream authors from changing the tarball
-they distribute without also upping the version number, so
+they distribute without also incrementing the version number, so
there can be no guarantee that a pristine tarball is identical
to what upstream <em>currently</em> distributing at any point in
time. All that can be expected is that it is identical to
@@ -5026,7 +5027,7 @@
<p>
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><package-name>@&pts-host;</tt>
+You can do so by using the <tt><package>@&pts-host;</tt>
email address.
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
@@ -5349,7 +5350,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 best solution is to file a regular bug containing the translation against
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.
Reply to: