reordered some subsections in the section about package uploads, it wasn't organized

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1274 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developers-reference.sgml b/developers-reference.sgml
index f64955c1f615143efec57b1d292507eec09b0037..c5fb33c28ad7ef95da21e2951ab56249c08452a5 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -5,7 +5,7 @@
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.68 $">
+  <!entity cvs-rev "$Revision: 1.69 $">
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
@@ -915,11 +915,38 @@ better feel of what is going on, and what is new, in the project.
          </list>
 
 
+      <sect id="upload-checking">Checking the package prior to upload
+         <p>
+Before you upload your package, you should do basic testing on it.  At
+a minimum, you should try the following activities (you'll need to
+have an older version of the same 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</prgn> over the package.  You can run
+<prgn>lintian</prgn> 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</prgn> generates, try adding the <tt>-i</tt>
+switch, which will cause <prgn>lintian</prgn> to output a very verbose
+description of the problem.
+               <p>
+Normally, a package should <em>not</em> be uploaded if it causes lintian
+to emit errors (they will start with <tt>E</tt>).
+               <p>
+For more information on <prgn>lintian</prgn>, see <ref id="lintian">.
+             <item>
+Downgrade the package to the previous version (if one exists) &mdash; this
+tests the <tt>postrm</tt> and <tt>prerm</tt> scripts.
+             <item>
+Remove the package, then reinstall it.
+           </list>
 
 
-      <sect id="uploading">Uploading a package
-
-       <sect1>Generating the changes file
+      <sect>Generating the changes file
          <p>
 When a package is uploaded to the Debian FTP archive, it must be
 accompanied by a <tt>.changes</tt> file, which gives directions to the
@@ -934,29 +961,10 @@ All of these fields are mandatory for a Debian upload.  See the list
 of control fields in the <url id="&url-debian-policy;" name="Debian
 Policy Manual"> for the contents of these fields.  You can close bugs
 automatically using the <tt>Description</tt> field, see <ref
-id="upload-bugfix">.  Only the <tt>Distribution</tt> field is
-discussed in this section, since it relates to the archive maintenance
-policies.
+id="upload-bugfix">.
 
 
-       <sect1 id="upload-dist">Picking a distribution
-         <p>
-Notably, the <tt>Distribution</tt> 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. Or, if Debian has been frozen, and you
-want to get a bug-fix release into <em>frozen</em>, you would set the
-distribution to `frozen unstable'.  (See <ref id="upload-frozen"> for
-more information on when to upload to <em>frozen</em>.)  Note that it
-never makes sense to combine the <em>experimental</em> distribution with
-anything else.
-         <p>
-You should avoid combining `stable' with others because of potential
-problems with library dependencies (for your package and for the package
-built by the build daemons for other architecture).
-See <ref id="upload-stable"> for more information on when and how to
-upload to <em>stable</em>.
+       <sect1>The original source tarball
          <p>
 The first time a version is uploaded which corresponds to a particular
 upstream version, the original source tar file should be uploaded and
@@ -979,6 +987,28 @@ is some reason why this is not the case, the new version of the
 original source should be uploaded, possibly by using the <tt>-sa</tt>
 flag.
 
+
+       <sect1 id="upload-dist">Picking a distribution
+         <p>
+The <tt>Distribution</tt> field, which originates from the
+<file>debian/changelog</file> file, indicates which distribution the
+package is intended for.
+         <p>
+There are four possible values for this
+field: `stable', `unstable', `frozen', or `experimental'; these values
+can also be combined. Or, if Debian has been frozen, and you
+want to get a bug-fix release into <em>frozen</em>, you would set the
+distribution to `frozen unstable'.  (See <ref id="upload-frozen"> for
+more information on when to upload to <em>frozen</em>.)  Note that it
+never makes sense to combine the <em>experimental</em> distribution with
+anything else.
+         <p>
+You should avoid combining `stable' with others because of potential
+problems with library dependencies (for your package and for the package
+built by the build daemons for other architecture).
+See <ref id="upload-stable"> for more information on when and how to
+upload to <em>stable</em>.
+
          <sect2 id="upload-frozen">Uploading to <em>frozen</em>
            <p>
 The Debian freeze is a crucial time for Debian.  It is our chance to
@@ -1058,36 +1088,7 @@ inclusion.
 
 
 
-       <sect1 id="upload-checking">Checking the package prior to upload
-         <p>
-Before you upload your package, you should do basic testing on it.  At
-a minimum, you should try the following activities (you'll need to
-have an older version of the same 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</prgn> over the package.  You can run
-<prgn>lintian</prgn> 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</prgn> generates, try adding the <tt>-i</tt>
-switch, which will cause <prgn>lintian</prgn> to output a very verbose
-description of the problem.
-               <p>
-Normally, a package should <em>not</em> be uploaded if it causes lintian
-to emit errors (they will start with <tt>E</tt>).
-               <p>
-For more information on <prgn>lintian</prgn>, see <ref id="lintian">.
-             <item>
-Downgrade the package to the previous version (if one exists) &mdash; this
-tests the <tt>postrm</tt> and <tt>prerm</tt> scripts.
-             <item>
-Remove the package, then reinstall it.
-           </list>
-
+      <sect id="uploading">Uploading a package
 
        <sect1 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
          <p>