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
</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>
</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.
<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>
</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.
<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>
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>
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
* Clarify that removals from testing are possible. Closes: #678710
Thanks to Per Andersson <avtobiff@gmail.com> for the patch.
+ * Reword various parts to be gender-neutral. Closes: #678712
+ Thanks to Per Andersson and Steve Langasek for the patch.
-- Raphaël Hertzog <hertzog@debian.org> Mon, 25 Jun 2012 20:46:20 +0200
<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>
</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>
<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>
<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>
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>
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.
<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
~ianmdlvl / developers-reference.git / commitdiff