Bug#678712: developers-reference: Please make developers reference gender neutral
Package: developers-reference
Version: 3.4.7
Severity: normal
Tags: patch
Dear Maintainer,
To honour the recent vote on diversity [0] please make the developers
reference gender neutral.
[0] http://www.debian.org/vote/2012/vote_002
See attached patch for a proposed update on the subject.
Best,
Per
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-4-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
developers-reference depends on no packages.
Versions of packages developers-reference recommends:
ii debian-policy 3.9.3.1
Versions of packages developers-reference suggests:
ii doc-base 0.10.3
-- no debconf information
Index: best-pkging-practices.dbk
===================================================================
--- best-pkging-practices.dbk (revision 9223)
+++ best-pkging-practices.dbk (working copy)
@@ -1630,8 +1630,8 @@
tarball is identical to what upstream <emphasis>currently</emphasis>
distributing at any point in time. All that can be expected is that it is
identical to something that upstream once <emphasis>did</emphasis> distribute.
-If a difference arises later (say, if upstream notices that he wasn't using
-maximal compression in his original distribution and then
+If a difference arises later (say, if upstream notices that they wasn't using
+maximal compression in their original distribution and then
re-<command>gzip</command>s it), that's just too bad. Since there is no good
way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
point in treating this situation as a bug. </para> </footnote> This makes it
@@ -1688,7 +1688,7 @@
</para>
<para>
In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
-file himself. We refer to such a tarball as a repackaged upstream
+file by themselves. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
@@ -1856,7 +1856,7 @@
</para>
<para>
The long description of the meta-package must clearly document its purpose
-so that the user knows what he will lose if he removes the package. Being
+so that the user knows what will be lost if the package is removed. Being
explicit about the consequences is recommended. This is particularly
important for meta-packages which are installed during initial
installation and that have not been explicitly installed by the user.
Index: beyond-pkging.dbk
===================================================================
--- beyond-pkging.dbk (revision 9223)
+++ beyond-pkging.dbk (working copy)
@@ -346,12 +346,12 @@
<para>The sponsor downloads (or checkouts) the source package.</para>
</listitem>
<listitem>
-<para>The sponsor reviews the source package. If she finds issues, she
-informs the maintainer and asks her to provide a fixed version (the
+<para>The sponsor reviews the source package. If the sponsor finds issues, they
+inform the maintainer and ask to provide a fixed version (the
process starts over at step 1).</para>
</listitem>
<listitem>
-<para>The sponsor could not find any remaining problem. She builds the
+<para>The sponsor could not find any remaining problem and builds the
package, signs it, and uploads it to Debian.</para>
</listitem>
</orderedlist>
@@ -369,15 +369,15 @@
</para>
<para>
You should also ensure that the prospective maintainer is going
-to be a good maintainer. Does she already have some experience with other
-packages? If yes, is she doing a good job with them (check out some bugs)?
-Is she familiar with the package and its programming language?
-Does she have the skills needed for this package? If not, is she able
+to be a good maintainer. Do they already have some experience with other
+packages? If yes, are they doing a good job with them (check out some bugs)?
+Are they familiar with the package and its programming language?
+Do they have the skills needed for this package? If not, are they able
to learn them?
</para>
<para>
-It's also a good idea to know where she stands towards Debian: does
-she agree with Debian's philosophy and does she intend to join Debian?
+It's also a good idea to know where they stands towards Debian: do
+they agree with Debian's philosophy and intend to join Debian?
Given how easy it is to become a Debian Maintainer, you might want
to only sponsor people who plan to join. That way you know from the start
that you won't have to act as a sponsor indefinitely.
@@ -473,7 +473,7 @@
<para>
If the audit did not reveal any problem, you can build the package and
upload it to Debian. Remember that even if you're not the maintainer,
-the sponsor is still responsible of what he uploaded to Debian. That's
+the sponsor is still responsible of what they uploaded to Debian. That's
why you're encouraged to keep up with the package through the
<xref linkend="pkg-tracking-system"/>.
</para>
@@ -482,7 +482,7 @@
in the <filename>changelog</filename> or in the <filename>control</filename> file. The <literal>Maintainer</literal>
field of the <filename>control</filename> file and the
<filename>changelog</filename> should list the person who did the
-packaging, i.e. the sponsoree. That way she will get all the BTS mail.
+packaging, i.e. the sponsoree. That way the sponsoree will get all the BTS mail.
</para>
<para>Instead you should instruct <command>dpkg-buildpackage</command> to use your key for
the signature. You do that with the <literal>-k</literal> option:</para>
@@ -539,11 +539,11 @@
maintainer has not missed something important. Maybe there are translations
updates sitting in the BTS that could have been integrated. Maybe the package
has been NMUed and the maintainer forgot to integrate the changes from the
-NMU in his package. Maybe there's a release critical bug that he has left
+NMU in the package. Maybe there's a release critical bug that they have left
unhandled and that's blocking migration to <literal>testing</literal>. Whatever. If you find
-something that she could have done (better), it's time to tell her so that
-she can improve for next time, and so that she has a better understanding
-of her responsibilities.
+something that could have been done (better), it's time to tell them so that
+they can improve for next time, and so that they have a better understanding
+of their responsibilities.
</para>
<para>
If you have found no major problem, upload the new version. Otherwise
Index: pkgs.dbk
===================================================================
--- pkgs.dbk (revision 9223)
+++ pkgs.dbk (working copy)
@@ -1955,11 +1955,11 @@
<listitem>
<para>
If the maintainer is usually active and responsive, have you tried to contact
-him? In general it should be considered preferable that a maintainer takes care
-of an issue himself and that he is given the chance to review and correct your
-patch, because he can be expected to be more aware of potential issues which an
-NMUer might miss. It is often a better use of everyone's time if the maintainer
-is given an opportunity to upload a fix on their own.
+the maintainer? In general it should be considered preferable that a maintainer
+takes care of an issue themselves and are given the chance to review and
+correct your patch, because they can be expected to be more aware of potential
+issues which an NMUer might miss. It is often a better use of everyone's time
+if the maintainer is given an opportunity to upload a fix on their own.
</para>
</listitem>
</itemizedlist>
@@ -2121,7 +2121,7 @@
same time. For instance, instead of telling the maintainer that you will
upload the updated
package in 7 days, you should upload the package to
-<literal>DELAYED/7</literal> and tell the maintainer that he has 7 days to
+<literal>DELAYED/7</literal> and tell the maintainer that they have 7 days to
react. During this time, the maintainer can ask you to delay the upload some
more, or cancel your upload.
</para>
@@ -2130,12 +2130,12 @@
The <literal>DELAYED</literal> queue should not be used to put additional
pressure on the maintainer. In particular, it's important that you are
available to cancel or delay the upload before the delay expires since the
-maintainer cannot cancel the upload himself.
+maintainer cannot cancel the upload themselves.
</para>
<para>
If you make an NMU to <literal>DELAYED</literal> and the maintainer updates
-his package before the delay expires, your upload will be rejected because a
+the package before the delay expires, your upload will be rejected because a
newer version is already available in the archive.
Ideally, the maintainer will take care to include your proposed changes (or
at least a solution for the problems they address) in that upload.
Index: resources.dbk
===================================================================
--- resources.dbk (revision 9223)
+++ resources.dbk (working copy)
@@ -627,7 +627,7 @@
<para>
Active development is done in the <literal>unstable</literal> distribution
(that's why this distribution is sometimes called the <literal>development
-distribution</literal>). Every Debian developer can update his or her
+distribution</literal>). Every Debian developer 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 made to make
sure everything in this distribution is working properly, it is sometimes
Reply to: