<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.57 $">
+ <!entity cvs-rev "$Revision: 1.60 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
<author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
- <version>ver. &version;, &date;
+ <version>ver. &version;, &date-en;
<copyright>
<copyrightsummary>
more information.
<p>
Assuming no one else is already working on your prospective package,
-you must then submit a short bug (<ref id="submit-bug">) against the
-pseudo package <tt>wnpp</tt> and send a copy to &email-debian-devel;
+you must then submit a bug report (<ref id="submit-bug">) against the
+pseudo package <tt>wnpp</tt>
describing your plan to create a new package, including, but not
limiting yourself to, a description of the package, the license of the
prospective package and the current URL where it can be downloaded
-from. You should set the subject of the bug to ``ITP: <var>foo</var>
+from.
+ <p>
+You should set the subject of the bug to ``ITP: <var>foo</var>
-- <var>short description</var>'', substituting the name of the new
-package for <var>foo</var>. The severity of the bug report must be
-set to <em>wishlist</em>. Please include a <tt>Closes:
-bug#<var>nnnnn</var></tt> entry on the changelog of the new package in
-order for the bug report to be automatically closed once the new
-package is installed on the archive (<ref id="upload-bugfix">).
+package for <var>foo</var>. The severity of the bug report must be set
+to <em>wishlist</em>. If you feel it's necessary, send a copy to
+&email-debian-devel; by putting the address in the X-Debbugs-CC: header
+of the message (no, don't use CC:, because that way the message's subject
+won't indicate the bug number).
+ <p>
+Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry on the
+changelog of the new package in order for the bug report to be
+automatically closed once the new package is installed on the archive
+(<ref id="upload-bugfix">).
<p>
There are a number of reasons why we ask maintainers to announce their
intentions:
against the pseudo package <package>wnpp</package>. The bug report should be
titled <tt>O: <var>package</var> -- <var>short description</var></tt>
indicating that the package is now orphaned. The severity of the bug
-should be set to <em>normal</em>. If the package is especially
-crucial to Debian, you should instead submit a bug against
-<tt>wnpp</tt> and title it <tt>RFA: <var>package</var> -- <var>short
-description</var></tt> and set its severity to <em>important</em>. You
-should also email &email-debian-devel; asking for a new maintainer.
+should be set to <em>normal</em>. If you feel it's necessary, send a copy
+to &email-debian-devel; by putting the address in the X-Debbugs-CC: header
+of the message (no, don't use CC:, because that way the message's subject
+won't indicate the bug number).
+ <p>
+If the package is especially crucial to Debian, you should instead submit
+a bug against <tt>wnpp</tt> and title it <tt>RFA: <var>package</var> --
+<var>short description</var></tt> and set its severity to
+<em>important</em>. Definitely copy the message to debian-devel in this
+case, as described above.
<p>
Read instructions on the <url id="&url-wnpp;" name="WNPP web pages">
for more information.
-
<chapt id="bug-handling">Handling Bugs
<sect>Monitoring bugs
list.
+ <chapt id="newmaint">
+ <heading>Interaction with prospective developers</heading>
+
+ <p>
+This chapter describes procedures that existing Debian developers should
+follow when it comes to dealing with wannabe developers.
+
+ <sect>Sponsoring packages
+ <p>
+Sponsoring a package means uploading a package for a maintainer who is not
+able to do it on their own, a new maintainer applicant. Sponsoring a package
+also means accepting responsibility for it.
+ <p>
+New maintainers usually have certain difficulties creating Debian packages
+-- this is quite understandable. That is why the sponsor is there, to check
+the package and verify that it is good enough for inclusion in Debian.
+(Note that if the sponsored package is new, the FTP admins will also have to
+inspect it before letting it in.)
+ <p>
+If you are an application manager for a prospective developer, you can also
+be their sponsor. That way you can also verify the how the applicant is
+handling the `Tasks and Skills' part of their application.
+
+ <sect>Advocating new developers
+ <p>
+See the page about <url id="&url-newmaint-advocate;"
+name="advocating a prospective developer"> at the Debian web site.
+
+ <sect>Handling new maintainer applications
+ <p>
+Please see <url id="&url-newmaint-amchecklist;" name="Checklist for
+Application Managers"> at the Debian web site.
+
+
+
<chapt id="tools">Overview of Debian Maintainer Tools
<p>
This section contains a rough overview of the tools available to
~ianmdlvl / developers-reference.git / blobdiff