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>
-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
-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 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
-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.
</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
-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>
-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
-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.
-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>
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
-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
-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
-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
~ianmdlvl / developers-reference.git / blobdiff