<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.115 $">
+ <!entity cvs-rev "$Revision: 1.116 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
<p>
A copy of the GNU General Public License is available as &file-GPL; in
the &debian-formal; distribution or on the World Wide Web at <url
-id="&url-gpl;" name="the GNU website">. You can also obtain it by
+id="&url-gpl;" name="the GNU web site">. You can also obtain it by
writing to the &fsf-addr;.
<toc detail="sect1">
on similar tasks. That way, you can learn from experienced developers.
For example, if you are interested in packaging existing software for
Debian you should try to get a sponsor. A sponsor will work together
-with you on your package and upload it to the Debian archive once he
-is happy with the packaging work you have done. You can find a sponsor
+with you on your package and upload it to the Debian archive once they
+are happy with the packaging work you have done. You can find a sponsor
by mailing the &email-debian-mentors; mailing list, describing your
package and yourself and asking for a sponsor (see <ref id="sponsoring">
for more information on sponsoring). On the other hand, if you are
<sect id="user-maint">Maintaining your Debian information
<p>
-There's a LDAP database containing many informations concerning all
+There's a LDAP database containing information about all
developers, you can access it at <url id="&url-debian-db;">. You can
update your password (this password is propagated to most of the machines
that are accessible to you), your address, your country, the latitude and
id="&url-pgp-faq;" name="PGP FAQ">.
<p>
If you add signatures to your public key, or add user identities, you
-can update the debian key ring by sending your key to the key server at
+can update the Debian key ring by sending your key to the key server at
<tt>&keyserver-host;</tt>. If you need to add a completely new key,
or remove an old key, send mail to &email-debian-keyring;. The same
key extraction routines discussed in <ref id="registering"> apply.
than 150 persons are always logged in. It's a channel for people who work
on Debian, it's not a support channel (there's <em>#debian</em> for that).
It is however open to anyone who wants to lurk (and learn). Its topic is
-always full of interesting informations. Since it's an open channel, you
+always full of interesting information. Since it's an open channel, you
should not speak there of issues that are discussed in
&email-debian-private;. There's a key protected channel
<em>#debian-private</em> for that purpose. The key is available
<sect id="doc-rsrcs">Documentation
<p>
-This document contains many informations very useful to Debian developers,
+This document contains a lot of information very useful to Debian developers,
but it can not contain everything. Most of the other interesting documents
are linked from <url id="&url-devel-docs;" name="The Developers' Corner">.
Take the time to browse all the links, you will learn many more things.
think that the system operators need to be notified of this problem,
please find the contact address for the particular machine at <url
id="&url-devel-machines;">. If you have a non-operating problems
-(such as packages to be remove, suggestions for the web site, etc.),
+(such as packages to be removed, suggestions for the web site, etc.),
generally you'll report a bug against a ``pseudo-package''. See <ref
id="submit-bug"> for information on how to submit bugs.
machine.
<p>
If you have some Debian-specific information which you want to serve
-up on the web, you can do this by putting material in the
+on the web, you can do this by putting material in the
<file>public_html</file> directory under your home directory. You should
do this on <tt>klecker.debian.org</tt>. Any material you put in those areas
are accessible via the URL
for people who are doing non-maintainer uploads. Instead of
waiting before uploading a NMU, it is uploaded as soon as it is
ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
-That leaves the corresponding number of days to the maintainer
-in order to react and upload himself another fix if he is not
-completely satisfied with the NMU. Alternatively he can remove
-the NMU by himself.
+That leaves the corresponding number of days for the maintainer
+to react and upload another fix themselves if they are not
+completely satisfied with the NMU. Alternatively they can remove
+the NMU.
<p>
The use of that delayed feature can be simplified with a bit
of integration with your upload tool. For instance, if you use
to keep someone informed of the progression of his packages in testing.
<p>
The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it by himself by looking
+why the package is refused, one may have to find it on their own by looking
what would break with the inclusion of the package. The <url
id="&url-testing-faq;" name="testing FAQ"> gives some more information
about the usual problems which may be causing such troubles.
<sect1 id="pkg-info-web">On the web
<p>
-Each package has several dedicated web pages that contains many
-informations. <tt>http://&packages-host;/<var>package-name</var></tt>
+Each package has several dedicated web pages that contain a lot of
+information. <tt>http://&packages-host;/<var>package-name</var></tt>
will display each version of the package
available in the various distributions. The per-version detailed
information includes the package description,
<item>
Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
<ref id="delayed-incoming">), send the final patch to the maintainer via
-the BTS, and explain him that he has 7 days to react if he wants to cancel
-the NMU.
+the BTS, and explain to them that they have 7 days to react if they want
+to cancel the NMU.
<item>
Follow what happens, you're responsible for any bug that you introduced
with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
entry of your next upload.
<p>
In any case, you should not be upset by the NMU. An NMU is not a
-personal attack against the maintainer. It is just the proof that
-someone cares enough about the package and was willing to help
-you in your work. You should be thankful to him and you may want to
-ask him if he would be interested to help you on a more frequent
+personal attack against the maintainer. It is a proof that
+someone cares enough about the package and that they were willing to help
+you in your work, so you should be thankful. You may also want to
+ask them if they would be interested to help you on a more frequent
basis as co-maintainer or backup maintainer
(see <ref id="collaborative-maint">).
<tt>Maintainer:</tt> field, although it can take a few hours after the
upload is done. If you do not expect to upload a new version for a while,
you can use <ref id="pkg-tracking-system"> to get the bug reports. However,
-make sure that the old maintainer is not embarrassed by the fact that
-he will continue to receive the bugs during that time.
+make sure that the old maintainer has no problem with the fact that
+they will continue to receive the bugs during that time.
<sect id="bug-handling">Handling package bugs
to be brought to the upstream author.
<p>
If the bug submitter disagree with your decision to close the bug,
-he may reopen it until you find an agreement on how to handle it.
+they may reopen it until you find an agreement on how to handle it.
If you don't find any, you may want to tag the bug <tt>wontfix</tt>
to let people know that the bug exists but that it won't be corrected.
If this situation is unacceptable, you (or the submitter) may want to
do the same with <prgn>debconf-mergetemplate</prgn>
(package <package>debconf-utils</package>).
<p>
-When the package maintainer needs to update the templates file, he only
-changes <file>debian/templates</file>. When English strings in this file
+When the package maintainer needs to update the templates file, they only
+change <file>debian/templates</file>. When English strings in this file
and in <file>debian/templates.xx</file> differ, translators do know that
their translation is outdated.
<p>
<p>
The description of the package (as defined by the corresponding field
in the <file>control</file> file) is usually the first information
-available to the user before he installs it. As such, it should
+available to the user before they install it. As such, it should
provide all the required information to let him decide whether
to install the package.
<p>
useful information about this maintainer. Start by logging into
the <url id="&url-debian-db;" name="Debian Developer's Database">
and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
-he maintains and any Release Critical bugs filled against them.
+and when they were last seen. Collect any important package names
+they maintain and any Release Critical bugs filed against them.
<p>
Send all this information to &email-debian-qa;, in order to let the
QA people do whatever is needed.
addresses) may be. Replace <tt><package></tt> with the name of
a source or a binary package.
<p>
-You may also be interested by contacting the persons who are
+You may also be interested in contacting the persons who are
subscribed to a given source package via <ref id="pkg-tracking-system">.
You can do so by using the <tt><package-name>@&pts-host;</tt>
email address.
theory, you should only ask only for the diff file, and the location of the
original source tarball, and then you should download the source and apply
the diff yourself. In practice, you may want to use the source package
-built by your sponsoree. In that case you have to check that he hasn't
-altered the upstream files in the <file>.orig.tar.gz</file> file that he's
-providing.
+built by your sponsoree. In that case, you have to check that they haven't
+altered the upstream files in the <file>.orig.tar.gz</file> file that
+they're providing.
<p>
Do not be afraid to write the sponsoree back and point out changes
that need to be made. It often takes several rounds of back-and-forth
~ianmdlvl / developers-reference.git / commitdiff