Style consistency: use <literal> tags whenever accurate

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@8583 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developer-duties.dbk b/developer-duties.dbk
index c8300f7e52019f4332b05a47acf03716cddb540a..120b89cbdc4afbb27b53a87b0d17db2c0164b294 100644 (file)
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -13,20 +13,20 @@ high-quality packages that are well integrated
 in the system and that adhere to the Debian Policy.</para>
 
 <section id="help-release">
 in the system and that adhere to the Debian Policy.</para>
 
 <section id="help-release">

-<title>Work towards the next stable release</title>
+<title>Work towards the next <literal>stable</literal> release</title>

 <para>
 <para>

-Providing high-quality packages in unstable is not enough, most users will
+Providing high-quality packages in <literal>unstable</literal> is not enough, most users will

 only benefit from your packages when they are released as part of the next
 only benefit from your packages when they are released as part of the next

-stable release. You are thus expected to collaborate with the release team
+<literal>stable</literal> release. You are thus expected to collaborate with the release team

 to ensure your packages get included.
 </para>
 <para>
 More concretely, you should monitor whether your packages are migrating
 to ensure your packages get included.
 </para>
 <para>
 More concretely, you should monitor whether your packages are migrating

-to testing (see <xref linkend="testing"/>). When the migration doesn't happen
+to <literal>testing</literal> (see <xref linkend="testing"/>). When the migration doesn't happen

 after the test period, you should analyze why and work towards fixing this.
 It might mean fixing your package (in the case of release-critical bugs or
 failures to build on some architecture) but it can also mean updating (or
 after the test period, you should analyze why and work towards fixing this.
 It might mean fixing your package (in the case of release-critical bugs or
 failures to build on some architecture) but it can also mean updating (or

-fixing, or removing from testing) other packages to help complete a
+fixing, or removing from <literal>testing</literal>) other packages to help complete a

 transition in which your package is entangled due to its dependencies. The
 release team might provide you some input on the current blockers of a
 given transition if you are not able to identify them.
 transition in which your package is entangled due to its dependencies. The
 release team might provide you some input on the current blockers of a
 given transition if you are not able to identify them.


@@ -34,20 +34,20 @@ given transition if you are not able to identify them.
 </section>
 
 <section id="maintain-stable">
 </section>
 
 <section id="maintain-stable">

-<title>Maintain packages in stable</title>
+<title>Maintain packages in <literal>stable</literal></title>

 <para>
 Most of the package maintainer's work goes into providing updated
 <para>
 Most of the package maintainer's work goes into providing updated

-versions of packages in unstable, but his job also entails taking care
-of the packages in the current stable release.
+versions of packages in <literal>unstable</literal>, but his job also entails taking care
+of the packages in the current <literal>stable</literal> release.

 </para>
 <para>
 </para>
 <para>

-While changes in stable are discouraged, they are possible. Whenever a
+While changes in <literal>stable</literal> are discouraged, they are possible. Whenever a

 security problem is reported, you should collaborate with the security
 team to provide a fixed version (see <xref linkend="bug-security"/>). When
 security problem is reported, you should collaborate with the security
 team to provide a fixed version (see <xref linkend="bug-security"/>). When

-bugs of severity important (or more) are reported against the stable
+bugs of severity important (or more) are reported against the <literal>stable</literal>

 version of your packages, you should consider providing a targeted fix.
 version of your packages, you should consider providing a targeted fix.

-You can ask the stable release team whether they would accept such an
-update and then prepare a stable upload (see <xref
+You can ask the <literal>stable</literal> release team whether they would accept such an
+update and then prepare a <literal>stable</literal> upload (see <xref

 linkend="upload-stable"/>).
 </para>
 </section>
 linkend="upload-stable"/>).
 </para>
 </section>


@@ -60,20 +60,20 @@ Generally you should deal with bug reports on your packages as described in
 that you need to take care of — the so-called release-critical bugs (RC
 bugs). All bug reports that have severity <literal>critical</literal>,
 <literal>grave</literal> or <literal>serious</literal> make the package
 that you need to take care of — the so-called release-critical bugs (RC
 bugs). All bug reports that have severity <literal>critical</literal>,
 <literal>grave</literal> or <literal>serious</literal> make the package

-unsuitable for inclusion in the next stable release.
+unsuitable for inclusion in the next <literal>stable</literal> release.

 They can thus delay the Debian release (when they affect a package in
 They can thus delay the Debian release (when they affect a package in

-testing) or block migrations to testing (when they only affect the package
-in unstable). In the worst scenario, they will lead to the package's
+<literal>testing</literal>) or block migrations to <literal>testing</literal> (when they only affect the package
+in <literal>unstable</literal>). In the worst scenario, they will lead to the package's

 removal. That's why these bugs need to be corrected as quickly as possible.
 </para>
 <para>
 If, for any reason, you aren't able fix an RC bug in a
 package of yours within 2 weeks (for example due to time constraints, or
 because it's difficult to fix), you should mention it clearly in the
 removal. That's why these bugs need to be corrected as quickly as possible.
 </para>
 <para>
 If, for any reason, you aren't able fix an RC bug in a
 package of yours within 2 weeks (for example due to time constraints, or
 because it's difficult to fix), you should mention it clearly in the

-bug report and you should tag the bug "help" to invite other
+bug report and you should tag the bug <literal>help</literal> to invite other

 volunteers to chime in. Be aware that RC bugs are frequently the targets
 of Non-Maintainer Uploads (see <xref linkend="nmu"/>) because they
 volunteers to chime in. Be aware that RC bugs are frequently the targets
 of Non-Maintainer Uploads (see <xref linkend="nmu"/>) because they

-can block the testing migration of many packages.
+can block the <literal>testing</literal> migration of many packages.

 </para>
 <para>
 Lack of attention to RC bugs is often interpreted by the QA team as a sign
 </para>
 <para>
 Lack of attention to RC bugs is often interpreted by the QA team as a sign