Package: developers-reference
Severity: minor
Tags: patch
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I was searching for gender-specific language to correct across all the
documentation that is part of DDP
* What exactly did you do (or not do) that was effective (or
ineffective)?
grep -r " he " ./* | grep .sgml
grep -r " his " ./* | grep .sgml
grep -r " him " ./* | grep .sgml
and ignored all the files that were included in a language-specific
folder other than english
* What was the outcome of this action?
I found some issues and created the patch attached here.
All the best,
Myriam
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: 2.11/developers-reference.sgml
===================================================================
--- 2.11/developers-reference.sgml (revision 10421)
+++ 2.11/developers-reference.sgml (working copy)
@@ -217,7 +217,7 @@
to verify your application (an <em>advocate</em>). After you have
contributed to Debian for a while, and you want to apply to become a
registered developer, an existing developer with whom you
-have worked over the past months has to express his belief that you
+have worked over the past months has to state the belief that you
can contribute to Debian successfully.
<p>
When you have found an advocate, have your GPG key signed and have
@@ -358,14 +358,14 @@
<p>
If you notice that a package is lacking maintenance, you should
make sure the maintainer is active and will continue to work on
-his packages. Try contacting him yourself.
+the packages. Try contacting the maintainer yourself.
<p>
If you do not get a reply after a few weeks you should collect all
useful information about this maintainer. Start by logging into
the <url id="&url-debian-db;" name="Debian Developer's Database">
and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
-he maintains and any Release Critical bugs filled against them.
+and when was last seen. Collect any important package names
+maintained by this person and any Release Critical bugs filled against them.
<p>
Send all this information to &email-debian-qa;, in order to let the
QA people do whatever is needed.
@@ -742,7 +742,7 @@
<p>
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
+distribution</em>). Debian developers can update their
packages in this distribution at any time. Thus, the contents of this
distribution change from day-to-day. Since no special effort is done
to make sure everything in this distribution is working properly, it is
Index: 3.0/developers-reference.sgml
===================================================================
--- 3.0/developers-reference.sgml (revision 10421)
+++ 3.0/developers-reference.sgml (working copy)
@@ -227,7 +227,7 @@
to verify your application (an <em>advocate</em>). After you have
contributed to Debian for a while, and you want to apply to become a
registered developer, an existing developer with whom you
-have worked over the past months has to express his belief that you
+have worked over the past months has to state the belief that you
can contribute to Debian successfully.
<p>
When you have found an advocate, have your GnuPG key signed and have
@@ -981,9 +981,9 @@
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.
That leaves the corresponding number of days to the maintainer
-in order to react and upload himself another fix if he is not
-completely satisfied with the NMU. Alternatively he can remove
-the NMU by himself.
+in order to react and upload autonomously another fix if not
+completely satisfied with the NMU. Alternatively the maintainer can directly remove
+the NMU.
<p>
The use of that delayed feature can be simplified with a bit
of integration with your upload tool. For instance, if you use
@@ -1042,7 +1042,7 @@
id="&url-testing-maint;">. Alternatively, it is possible to use
the <prgn>grep-excuses</prgn> program part of the
<package>devscripts</package> package. It can be easily put in a crontab
-to keep someone informed of the progression of his packages in testing.
+to keep someone informed of the progression of the packages in testing.
<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 by himself by looking
@@ -1053,7 +1053,7 @@
Sometimes, some packages never enter testing because the set of
inter-relationship is too complicated and can not be sorted out
by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
+contacted to force the inclusion of the packages.
<sect id="pkg-info">Package's information
<p>
@@ -1822,11 +1822,11 @@
(BTS). If not, submit a bug.
<item>
Wait a few days the response from the maintainer. If you don't get
-any response, you may want to help him by sending the patch that fixes
+any response, you may want to help by sending the patch that fixes
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 him a mail announcing your intent to NMU the package.
+maintainer, contact the person by e-mail announcing your intent to NMU the package.
Prepare an NMU as described in <ref id="nmu-guidelines">, test it
carefully on your machine (cf. <ref id="upload-checking">).
Double check that your patch doesn't have any unexpected side effects.
@@ -1834,7 +1834,7 @@
<item>
Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
<ref id="delayed-incoming">), send the final patch to the maintainer via
-the BTS, and explain him that he has 7 days to react if he wants to cancel
+the BTS, and explain that there are 7 days for the maintainer to react if wishing to cancel
the NMU.
<item>
Follow what happens, you're responsible for any bug that you introduced
@@ -1977,8 +1977,8 @@
In any case, you should not be upset by the NMU. An NMU is not a
personal attack against the maintainer. It is just the proof that
someone cares enough about the package and was willing to help
-you in your work. You should be thankful to him and you may want to
-ask him if he would be interested to help you on a more frequent
+you in your work. You should be thankful to the NMU and you may want to
+inquire whether this person is willing to help you on a more frequent
basis as co-maintainer or backup maintainer
(see <ref id="collaborative-maint">).
@@ -2476,7 +2476,7 @@
Decide whether the report corresponds to a real bug or not. Sometimes
users are just calling a program in the wrong way because they haven't
read the documentation. If you diagnose this, just close the bug with
-enough information to let the user correct his problem (give pointers
+enough information to let the user correct the problem (give pointers
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
@@ -2507,7 +2507,7 @@
change is just cosmetic.
<item>
The bug submitter may have forgotten to provide some information, in that
-case you have to ask him the information required. You may use the
+case you have to ask for the information required. You may use the
<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
can reproduce the bug is then invited to provide more information
@@ -2694,8 +2694,7 @@
do the same with <prgn>debconf-mergetemplate</prgn>
(package <package>debconf-utils</package>).
<p>
-When the package maintainer needs to update the templates file, he only
-changes <file>debian/templates</file>. When English strings in this file
+When the package maintainer needs to update the templates file, only <file>debian/templates</file> need to be changed. When English strings in this file
and in <file>debian/templates.xx</file> differ, translators do know that
their translation is outdated.
<p>
@@ -2789,8 +2788,8 @@
<p>
The description of the package (as defined by the corresponding field
in the <file>control</file> file) is usually the first information
-available to the user before he installs it. As such, it should
-provide all the required information to let him decide whether
+available to the user before the installation. As such, it should
+provide all the required information to let the user decide whether
to install the package.
<p>
For example, apart from the usual description that you adapt from the
@@ -2883,13 +2882,13 @@
<p>
If you notice that a package is lacking maintenance, you should
make sure the maintainer is active and will continue to work on
-his packages. Try contacting him yourself.
+the packages. Try contacting the maintainer by yourself.
<p>
If you do not get a reply after a few weeks you should collect all
useful information about this maintainer. Start by logging into
the <url id="&url-debian-db;" name="Debian Developer's Database">
and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
+and when was last seen. Collect any important package names
he maintains and any Release Critical bugs filled against them.
<p>
Send all this information to &email-debian-qa;, in order to let the
@@ -2961,9 +2960,7 @@
theory, you should only ask only 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
-built by your sponsoree. In that case you have to check that he hasn't
-altered the upstream files in the <file>.orig.tar.gz</file> file that he's
-providing.
+built by your sponsoree. In that case you have to check that the upstream files in the <file>.orig.tar.gz</file> file provided by your sponsoree hadn't been altered.
<p>
Do not be afraid to write the sponsoree back and point out changes
that need to be made. It often takes several rounds of back-and-forth
Index: 3.3.8/developers-reference.sgml
===================================================================
--- 3.3.8/developers-reference.sgml (revision 10421)
+++ 3.3.8/developers-reference.sgml (working copy)
@@ -4829,8 +4829,7 @@
time. All that can be expected is that it is identical to
something that upstream once <em>did</em> distribute.
-If a difference arises later (say, if upstream notices that he wasn't
-using maximal comression in his original distribution and then
+If a difference arises later (say, if upstream notices that maximal comression hadn't been used in the original distribution and then
re-<tt>gzip</tt>s it), that's just too bad. Since there is no good way
to upload a new .orig.tar.gz for the same version, there is not even
any point in treating this situation as a bug.
Attachment:
signature.asc
Description: OpenPGP digital signature