<para>
When you become aware of a security-related bug in a Debian package, whether or
not you are the maintainer, collect pertinent information about the problem,
-and promptly contact the security team, preferably by filing a ticket in
-their Request Tracker.
-See <ulink url="http://wiki.debian.org/rt.debian.org#Security_Team"></ulink>.
-Alternatively you may email &email-security-team;.
+and promptly contact the security team by emailing &email-security-team;. If
+desired, email can be encrypted with the Debian Security Contact key, see
+<ulink url="https://www.debian.org/security/faq#contact"/> for details.
<emphasis role="strong">DO NOT UPLOAD</emphasis> any packages for
<literal>stable</literal> without contacting the team. Useful information
includes, for example:
--compare-versions</literal>. Be careful not to re-use a version number that
you have already used for a previous upload, or one that conflicts with a
binNMU. The convention is to append
-<literal>+</literal><replaceable>codename</replaceable><literal>1</literal>, e.g.
-<literal>1:2.4.3-4+lenny1</literal>, of course increasing 1 for any subsequent
+<literal>+deb</literal><replaceable>X</replaceable><literal>u1</literal> (where
+<replaceable>X</replaceable> is the major release number), e.g.
+<literal>1:2.4.3-4+deb7u1</literal>, of course increasing 1 for any subsequent
uploads.
</para>
</listitem>
<itemizedlist>
<listitem>
<para>
-Does your NMU really fix bugs? Fixing cosmetic issues or changing the
-packaging style in NMUs is discouraged.
+Have you geared the NMU towards helping the maintainer? As there might
+be disagreement on the notion of whether the maintainer actually needs
+help on not, the DELAYED queue exists to give time to the maintainer to
+react and has the beneficial side-effect of allowing for independent
+reviews of the NMU diff.
+</para>
+</listitem>
+<listitem>
+<para>
+Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
+wishlist bugs for packaging a new upstream version, but care should be
+taken to minimize the impact to the maintainer.) Fixing cosmetic issues
+or changing the packaging style (e.g. switching from cdbs to dh) in NMUs
+is discouraged.
</para>
</listitem>
<listitem>
<para>
Those delays are only examples. In some cases, such as uploads fixing security
-issues, or fixes for trivial bugs that blocking a transition, it is desirable
+issues, or fixes for trivial bugs that block a transition, it is desirable
that the fixed package reaches <literal>unstable</literal> sooner.
</para>