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>
Attachment:
signature.asc
Description: OpenPGP digital signature