header (don't use CC:, because that way the message's subject won't
indicate the bug number). If you are packaging so many new packages (>10)
that notifying the mailing list in seperate messages is too disruptive,
-do send a summary after filing the bugs to the debian-devel list instead.
+send a summary after filing the bugs to the debian-devel list instead.
This will inform the other developers about upcoming packages and will
allow a review of your description and package name.
</para>
<para>
-Please include a <literal>Closes:
-bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the
-new package in order for the bug report to be automatically closed once the new
-package is installed in the archive (see <xref linkend="upload-bugfix"/> ).
+Please include a <literal>Closes: #<replaceable>nnnnn</replaceable></literal>
+entry in the changelog of the new package in order for the bug report to
+be automatically closed once the new package is installed in the archive
+(see <xref linkend="upload-bugfix"/>).
</para>
<para>
If you think your package needs some explanations for the administrators of the
<title>Special case: uploads to the <literal>stable</literal> and
<literal>oldstable</literal> distributions</title>
<para>
-Uploading to <literal>stable</literal> means that the package will transfered
+Uploading to <literal>stable</literal> means that the package will transferred
to the <literal>proposed-updates-new</literal> queue for review by the stable
release managers, and if approved will be installed in
<filename>stable-proposed-updates</filename> directory of the Debian archive.
<title>The Security Tracker</title>
<para>
The security team maintains a central database, the
-<ulink url="http://security-tracker.debian.net/">Debian Security Tracker</ulink>.
+<ulink url="http://security-tracker.debian.org/">Debian Security Tracker</ulink>.
This contains all public information that is known about security issues:
which packages and versions are affected or fixed, and thus whether stable,
testing and/or unstable are vulnerable. Information that is still confidential
</para>
<para>
The Security Team has a PGP-key to enable encrypted communication about
-sensitive issues. See the <ulink url="http://www.debian.org/security/faq.en.html#contact">Security Team FAQ</ulink> for details.
+sensitive issues. See the <ulink url="http://www.debian.org/security/faq#contact">Security Team FAQ</ulink> for details.
</para>
</section>
<emphasis role="strong">Target the right distribution</emphasis>
in your <filename>debian/changelog</filename>.
For <literal>stable</literal> this is <literal>stable-security</literal> and
-for testing this is <literal>testing-security</literal>, and for the previous
+for <literal>testing</literal> this is <literal>testing-security</literal>, and for the previous
stable release, this is <literal>oldstable-security</literal>. Do not target
<replaceable>distribution</replaceable><literal>-proposed-updates</literal> or
<literal>stable</literal>!
In order to prevent autobuilders from needlessly trying to build your package,
it must be included in <filename>packages-arch-specific</filename>, a list used
by the <command>wanna-build</command> script. The current version is available
-as <ulink
-url="&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak"></ulink>;
+as <ulink url="&url-buildd-p-a-s;"/>;
please see the top of the file for whom to contact for changes.
</para>
</listitem>
</section>
+<section id="nmu-team-upload">
+<title>NMUs vs team uploads</title>
+
+<para>
+Sometimes you are fixing and/or updating a package because you are member of a
+packaging team (which uses a mailing list as Maintainer or Uploader, see <xref
+linkend="collaborative-maint"/>) but you don't want to add yourself to Uploaders
+because you do not plan to contribute regularly to this specific package. If it
+conforms with your team's policy, you can perform a normal upload without
+being listed directly as Maintainer or Uploader. In that case, you should
+start your changelog entry with the following line: <code> * Team upload.</code>.
+</para>
+
+</section>
+
</section>
<section id="collaborative-maint">
</para>
</listitem>
</orderedlist>
+
<para>
In any case, it is a bad idea to automatically put all team members in the
-Uploaders field. It clutters the Developer's Package Overview listing (see
+Uploaders field. It clutters the Developer's Package Overview listing (see
<xref linkend="ddpo"/> ) with packages one doesn't really care for, and creates
-a false sense of good maintenance.
+a false sense of good maintenance. For the same reason, team members do
+not need to add themselves to the Uploaders field just because they are
+uploading the package once, they can do a “Team upload” (see <xref
+linkend="nmu-team-upload"/>). Conversely, it it a bad idea to keep a
+package with only the mailing list address as a Maintainer and no
+Uploaders.
</para>
</section>
~ianmdlvl / developers-reference.git / blobdiff