Steve Langasek <vorlon@debian.org> (23/06/2012):
> Attached is a corrected patch, which fixes the verb agreement issue above
> and makes a few other tweaks (e.g., not introducing passive tense where it's
> not needed, which is worse than the original problem it aims to fix), and
> also catches a few more gender-specific pronouns that were overlooked.
Looks good to my froggy eyes.
Seconded.
> Index: developer-duties.dbk
> ===================================================================
> --- developer-duties.dbk (revision 9223)
> +++ developer-duties.dbk (working copy)
> @@ -37,7 +37,7 @@
> <title>Maintain packages in <literal>stable</literal></title>
> <para>
> Most of the package maintainer's work goes into providing updated
> -versions of packages in <literal>unstable</literal>, but his job also entails taking care
> +versions of packages in <literal>unstable</literal>, but their job also entails taking care
> of the packages in the current <literal>stable</literal> release.
> </para>
> <para>
> @@ -77,7 +77,7 @@
> </para>
> <para>
> Lack of attention to RC bugs is often interpreted by the QA team as a sign
> -that the maintainer has disappeared without properly orphaning his package.
> +that the maintainer has disappeared without properly orphaning their package.
> The MIA team might also get involved, which could result in your packages
> being orphaned (see <xref linkend="mia-qa" />).
> </para>
> Index: best-pkging-practices.dbk
> ===================================================================
> --- best-pkging-practices.dbk (revision 9223)
> +++ best-pkging-practices.dbk (working copy)
> @@ -1630,9 +1630,9 @@
> 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
> -re-<command>gzip</command>s it), that's just too bad. Since there is no good
> +If a difference arises later (say, if upstream notice that they weren't using
> +maximal compression in their original distribution and then
> +re-<command>gzip</command> 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
> possible to use checksums to easily verify that all changes between Debian's
> @@ -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 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 they will lose if they remove the package. 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,13 +346,13 @@
> <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 they find issues, they
> +inform the maintainer and ask them 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
> -package, signs it, and uploads it to Debian.</para>
> +<para>The sponsor could not find any remaining problem. They build the
> +package, sign it, and upload it to Debian.</para>
> </listitem>
> </orderedlist>
> </para>
> @@ -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 stand with respect to Debian: do
> +they agree with Debian's philosophy and do they 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
> +as a sponsor you are still responsible for what you upload 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 they 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
> -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.
> +NMU into their package. Maybe there's a release critical bug that they have
> +left unhandled and that's blocking migration to <literal>testing</literal>.
> +If you find something that they could have 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.
> +them? In general it should be considered preferable that maintainers take care
> +of an issue themselves and that they 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
> Index: l10n.dbk
> ===================================================================
> --- l10n.dbk (revision 9223)
> +++ l10n.dbk (working copy)
> @@ -158,7 +158,7 @@
> <title>How to handle a bug report concerning a translation</title>
> <para>
> 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
> +it to both the previous translator and their team (using the corresponding
> debian-l10n-XXX mailing list).
> <!-- TODO: add the i18n tag to the bug? -->
> </para>
Mraw,
KiBi.
Attachment:
signature.asc
Description: Digital signature