+All of these fields are mandatory for a Debian upload. See the list
+of control fields in the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual"> for the contents of these fields.
+Only the <tt/Distribution/ field is discussed here, since it relates
+to the archive maintenance policies.
+
+ <sect1 id="upload-dist">Picking a distribution
+ <p>
+Notably, the <tt/Distribution/ field, which originates from the
+<file>debian/changelog</file> file, indicates which distribution the
+package is intended for. There are four possible values for this
+field: `stable', `unstable', `frozen', or `experimental'; these values
+can also be combined. For instance, if you have a crucial security
+fix release of a package, and the package has not diverged between the
+<em/stable/ and <em/unstable/ distributions, then you might put
+`stable unstable' in the <file>changelog</file>'s <tt/Distribution/ field.
+Or, if Debian has been frozen, and you want to get a bug-fix release
+into <em/frozen/, you would set the distribution to `frozen unstable'.
+(See <ref id="upload-frozen"> for more information on when to upload to
+<em/frozen/.) Note that setting the distribution to `stable' means
+that the package will be placed into the <tt>proposed-updates</tt>
+directory of the Debian archive for further testing before it is
+actually included in <em/stable/. Also note that it never makes sense
+to combine the <em/experimental/ distribution with anything else.
+ <p>
+The first time a version is uploaded which corresponds to a particular
+upstream version the original source tar file should be uploaded and
+included in the <tt/.changes/ file; subsequent times the very same tar
+file should be used to build the new diffs and <tt/.dsc/ files, and it
+need not then be uploaded.
+ <p>
+By default <prgn/dpkg-genchanges/ and <prgn/dpkg-buildpackage/ will
+include the original source tar file if and only if the Debian
+revision part of the source version number is <tt/0/ or <tt/1/,
+indicating a new upstream version. This behaviour may be modified by
+using <tt/-sa/ to always include it or <tt/-sd/ to always leave it
+out.
+ <p>
+If no original source is included in the upload then the original
+source tar-file used by <prgn/dpkg-source/ when constructing the
+<tt/.dsc/ file and diff to be uploaded <em/must/ be byte-for-byte
+identical with the one already in the archive. If there is some
+reason why this is not the case then the new version of the original
+source should be uploaded, possibly by using the <tt/-sa/ flag.
+
+ <sect2 id="upload-frozen">Uploading to <em/frozen/
+ <p>
+The Debian freeze is a crucial time for Debian. It is our chance to
+synchronize and stabilize our distribution as a whole. Therefore,
+care must be taken when uploading to <em/frozen/.
+ <p>
+It is tempting to always try to get the newest release of software
+into the release. However, it's much more important that the system
+as a whole is stable and works as expected.
+ <p>
+The watchword for uploading to <em/frozen/ is <strong>no new
+code</strong>. This is a difficult thing to quantify, so here are
+some guidelines:
+ <p>
+<list>
+ <item>
+Fixes for bugs of severity <em/critical/, <em/grave/, or
+<em/important/ severity are always allowed for those packages that
+must exist in the final release
+ <item>
+<em/critical/, <em/grave/, and <em/important/ bug fixes are only
+allowed for non-necessary packages if they don't add any new features
+ <item>
+normal bug fixes are allowed (though discouraged) on all packages if
+and only if there are no new features
+ <item>
+wishlist fixes are not allowed (they are, after all, not really bugs)
+ <item>
+documentation bug fixes are allowed, since good documentation is
+important
+ </list>
+ <p>
+Remember, there is statistically a 15% chance that every bug fix will
+introduce a new bug. The introduction and discovery of new bugs
+either delays release or weakens the final product. There is little
+correlation between the severity of the original bug and the severity
+of the introduced bug.
+
+
+
+ <sect1 id="upload-checking">Checking the package prior to upload
+ <p>
+Before you upload your package, you should do basic testing on it.
+Make sure you try the following activities (you'll need to have an
+older version of the Debian package around).
+<list>
+ <item>
+Install the package and make sure the software works, or upgrade the
+package from an older version to your new version if a Debian package
+for it already exists.
+ <item>
+Run <prgn/lintian/ over the package. You can run <prgn/lintian/ as
+follows: <tt>lintian -v <var>package-version</var>.changes</tt>. This will
+check the source package as well as the binary package. If you don't
+understand the output that <prgn/lintian/ generates, try adding the
+<tt/-i/ switch, which will cause <prgn/lintian/ to output a very
+verbose description of the problem.
+ <p>
+Normally, a package should <em/not/ be uploaded if it causes lintian
+to emit errors (they will start with <tt/E/).
+ <p>
+For more information on <prgn/lintian/, see <ref id="lintian">.
+ <item>
+Downgrade the package to the previous version (if one exists) -- this
+tests the <tt/postrm/ and <tt/prerm/ scripts.
+ <item>
+Remove the package, then reinstall it.
+ </list>
+
+
+ <sect1 id="upload-master">Uploading to <tt/master/
+ <p>
+To upload a package, you need a personal account on
+<ftpsite>master.debian.org</ftpsite>. All maintainers should already
+have this account, see <ref id="servers-master">. You can use either
+<prgn/ssh/ or <prgn/ftp/ to transfer the files. In either case, the
+files need to be placed into
+<ftppath>/home/Debian/ftp/private/project/Incoming</ftppath>. (You
+cannot upload to Incoming on master using anonymous FTP -- you must
+use your user-name and password.)
+ <p>
+<em/Note:/ Do not upload packages containing software that is
+export-controlled by the United States government to <tt/master/, or
+to the overseas upload queues on <tt/chiark/ or <tt/erlangen/. This
+prohibition covers almost all cryptographic software, and even
+sometimes software that contains ``hooks'' to cryptographic software,
+such as electronic mail readers that support PGP encryption and
+authentication. Uploads of such software should go to <tt/non-us/
+(see below). If you are not sure whether U.S. export controls apply
+to your package, post a message to
+<email/debian-devel@lists.debian.org/ and ask.
+ <p>
+You may also find the Debian package <package/dupload/ useful when
+uploading packages. This handy program is distributed with defaults
+for uploading via <prgn/ftp/ to <tt/master/, <tt/chiark/, and
+<tt/erlangen/. It can also be configured to use <prgn/ssh/. See
+<manref name="dupload" section="1"> and <manref name="dupload"
+section="5"> for more information.
+
+
+ <sect1>Uploads via <tt/chiark/
+ <p>
+If you have a slow network connection to <tt/master/, there are
+alternatives. One is to upload files to <tt/Incoming/ via a
+cron-driven upload queue in Europe on <tt/chiark/. For details connect
+to <ftpsite>ftp.chiark.greenend.org.uk</ftpsite> using anonymous FTP
+and read
+<ftppath>/pub/debian/private/project/README.how-to-upload</ftppath>.
+ <p>
+<em/Note:/ Do not upload packages containing software that is
+export-controlled by the United States government to the queue on
+<tt/chiark/. Since this upload queue goes to <tt/master/, the
+prescription found in <ref id="upload-master"> applies here as well.
+ <p>
+The program <tt/dupload/ supports uploads to <tt/chiark/; please refer
+to the documentation that comes with the program for details.
+
+
+ <sect1>Uploads via <tt/erlangen/
+ <p>
+Another cron-driven upload queue is available in Germany: just upload
+the files via anonymous FTP to <url
+id="ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue">.
+ <p>
+The upload must be a complete Debian upload, as you would put it into
+<tt/master/'s <tt/Incoming/, i.e., a <tt/.changes/ files along with the
+other files mentioned in the <tt/.changes/. The queue daemon also
+checks that the <tt/.changes/ is correctly PGP-signed by a Debian
+developer, so that no bogus files can find their way to <tt/master/
+via the queue. Please also make sure that the <tt/Maintainer/ field
+in the <tt/.changes/ contains <em/your/ e-mail address. The address
+found there is used for all replies, just as on <tt/master/.
+ <p>
+There's no need to move your files into a second directory after the
+upload as on <tt/chiark/. And, in any case, you should get some mail
+reply from the queue daemon what happened to your upload. Hopefully it
+should have been moved to <tt/master/, but in case of errors you're
+notified, too.
+ <p>
+<em/Note:/ Do not upload packages containing software that is
+export-controlled by the United States government to the queue on
+<tt/erlangen/. Since this upload queue goes to <tt/master/, the
+prescription found in <ref id="upload-master"> applies here as well.
+ <p>
+The program <prgn/dupload/ supports uploads to <tt/erlangen/; please refer
+to the documentation that comes with the program for details.
+