<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.59 $">
+ <!entity cvs-rev "$Revision: 1.63 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
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
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
-
<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