<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.112 $">
+ <!entity cvs-rev "$Revision: 1.116 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
<copyright>
<copyrightsummary>
-copyright ©1998–2002 Adam Di Carlo</copyrightsummary>
+copyright ©1998—2002 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
copyright ©1997, 1998 Christian Schwarz</copyrightsummary>
<p>
<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
2440">.
<p>
The recommended public key algorithm for use in Debian development
-work is the DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
+work is DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
types may be used however. Your key length must be at least 1024
bits; there is no reason to use a smaller key, and doing so would be
much less secure. Your key must be signed with at least your own user
<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.
may want to subscribe to &email-debian-vote;.
<p>
The list of all the proposals (past and current) is available on the
-web at <url id="url-vote">. You will find there additional information
-about how to make a vote proposal.
+<url id="&url-vote;" name="Debian Voting Information"> page. You will find
+there additional information about how to make a vote proposal.
<sect id="inform-vacation">Going on vacation gracefully
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
This development cycle is based on the assumption that the
<em>unstable</em> distribution becomes <em>stable</em> after passing a
period of being in <em>testing</em>. Even once a distribution is
-considered stable, a few bugs inevitably remain &mdash that's why the
+considered stable, a few bugs inevitably remain — that's why the
stable distribution is updated every now and then. However, these
updates are tested very carefully and have to be introduced into the
archive individually to reduce the risk of introducing new bugs. You
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
fqdn => "&ftp-master-host;",
login => "yourdebianlogin",
incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
- visibleuser => "yourdebianlogin",
- visiblename => "debian.org",
- fullname => "Your Full Name",
dinstall_runs => 1,
method => "scpb"
};
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>
by the author, you may also want to warn the user that the
package is not ready for production use.
<p>
+For consistency and for an aesthetic concern, you should capitalize the
+first letter of the description.
+ <p>
Last but not least, since the first user impression is based on
that description, you should be careful to avoid English
mistakes. Ensure that you spell check it.
<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that:
-<example>ispell -d american -g debian/control</example>
+<example>ispell -d american -g debian/control</example>.
+
<sect1 id="submit-many-bugs">Reporting lots of bugs at once
<p>
Reporting a great number of bugs for the same problem on a great
-number of different packages &mdash i.e., more than 10 &mdash is a deprecated
+number of different packages — i.e., more than 10 — is a deprecated
practice. Take all possible steps to avoid submitting bulk bugs at
all. For instance, if checking for the problem can be automated, add
a new check to <package>lintian</package> so that an error or warning
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 / blobdiff