<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.55 $">
+ <!entity cvs-rev "$Revision: 1.63 $">
<!-- 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>
<sect id="upstream-coordination">Coordination With Upstream Developers
<p>
A big part of your job as Debian maintainer will be to stay in contact
-with the upstream developers since you'll have to share information that
-you get from the Bug Tracking System. It's not your job to fix non-Debian
-specific bugs.
-Rather, you have to forward these bugs to the upstream developers.
-(Of course, if you are able to do so, you may certainly fix them...)
-This way, the bug will hopefully
-be corrected when the next upstream version comes out.
+with the upstream developers. Debian users will sometimes report bugs
+to the Bug Tracking System that are not specific to Debian. You
+must forward these bug reports to the upstream developers so that
+they can be fixed in a future release. It's not your job to fix
+non-Debian specific bugs. However, if you are able to do so, you are
+encouraged to contribute to upstream development of the package by
+providing a fix for the bug. Debian users and developers will often
+submit patches to fix upstream bugs, and you should evaluate and
+forward these patches upstream.
<p>
-From time to
-time, you may get a patch attached to a bug report. You have to send the
-patch upstream and make sure that it gets included (if the authors accept
-the proposed fix). If you need to modify the upstream sources in order to
-build a policy conformant package, then you should propose a nice fix
-to the upstream developers which can be included there, so that you won't have to
+If you need to modify the upstream sources in order to build a policy
+conformant package, then you should propose a nice fix to the upstream
+developers which can be included there, so that you won't have to
modify the sources of the next upstream version. Whatever changes you
need, always try not to fork from the upstream sources.
server. For instance, at the mirror site,
<ftpsite>ftp.us.debian.org</ftpsite>, the Debian archive itself is
contained in <ftppath>/debian</ftppath>, which is a common location
-(another is <ftppath>/pub/debian</ftppath>).
+(another is <tt>/pub/debian</tt>).
<p>
A distribution is comprised of Debian source and binary packages, and the
respective <tt>Sources</tt> and <tt>Packages</tt> index files, containing
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:
To upload a package, you need a personal account on
<ftpsite>ftp-master.debian.org</ftpsite>, which you should have as an
official maintainer. If you use <prgn>scp</prgn> or <prgn>rsync</prgn>
-to transfer the files, place them into <ftppath>&us-upload-dir;</ftppath>;
+to transfer the files, place them into <tt>&us-upload-dir;</tt>;
if you use anonymous FTP to upload, place them into
<ftppath>/pub/UploadQueue/</ftppath>.
<p>
<sect1 id="upload-non-us">Uploading to <tt>non-US</tt> (pandora)
<p>
As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, use <prgn>scp</prgn> or non-anonymous
-FTP to copy the package to <ftpsite>non-us.debian.org</ftpsite>, placing
-the files in <ftppath>&non-us-upload-dir;</ftppath>. By default, you can
+to <tt>ftp-master</tt>. Instead, use <prgn>scp</prgn> or <prgn>rsync</prgn>
+to copy the package to <ftpsite>non-us.debian.org</ftpsite>, placing
+the files in <tt>&non-us-upload-dir;</tt>. By default, you can
use the same account/password that works on <tt>ftp-master</tt>.
+If you use anonymous FTP to upload, place the files into
+<ftppath>/pub/UploadQueue/</ftppath>.
<p>
The program <prgn>dupload</prgn> comes with support for uploading to
<tt>non-us</tt>; please refer to the documentation that comes with
``foo_1.3-1.0.1''.
<p>
The way to invoke <prgn>dpkg-buildpackage</prgn> is as
-<tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>. Of course,
+<tt>dpkg-buildpackage -B -e<var>porter-email</var></tt>. Of course,
set <var>porter-email</var> to your email address. This will do a
binary-only build of only the architecture-dependant portions of the
package, using the `binary-arch' target in <file>debian/rules</file>.
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>
+Sponsoring merely by signing the upload or just recompiling is
+<strong>definitely not recommended</strong>. You need to build the source
+package just like you would build a package of your own. Remember that it
+doesn't matter that you left the prospective developer's name both in the
+changelog and the control file, the upload can still be traced to you.
+ <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