On 24/06/12 01:52, Cyril Brulebois wrote: > Looks good to my froggy eyes. > > Seconded.
Also seconded. (I'm a native en_GB speaker, for what it's worth.)
>> 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>
signature.asc
Description: OpenPGP digital signature
