purge references to 'frozen' distribution, which doesn't exist anymore

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

diff --git a/common.ent b/common.ent
index 61d5ae1071db067eebffc2d01d97c63a8027f00e..fd045b2cf7bd86bdd2743e0a12fb12dd2f8c0f3a 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -63,6 +63,8 @@
 <!entity url-debian-keyring "ftp://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
 <!entity url-readme-non-us "ftp://&ftp-debian-org;/debian/README.non-US">
 
 <!entity url-debian-keyring "ftp://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
 <!entity url-readme-non-us "ftp://&ftp-debian-org;/debian/README.non-US">
 

+<!entity url-testing-maint "http://ftp-master.debian.org/testing/">
+

 <!entity us-upload-dir "/org/ftp.debian.org/incoming/">
 <!entity non-us-upload-dir "/org/non-us.debian.org/incoming/">
 <!entity url-chiark-readme "ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload">
 <!entity us-upload-dir "/org/ftp.debian.org/incoming/">
 <!entity non-us-upload-dir "/org/non-us.debian.org/incoming/">
 <!entity url-chiark-readme "ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload">

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 2d7a1d5cab2d3c8a379516efe6791f0241d7cea6..0345fa47395d070d110fbc539e89f9da242490ee 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 -->
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->

-  <!entity cvs-rev "$Revision: 1.77 $">
+  <!entity cvs-rev "$Revision: 1.78 $">

 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->


@@ -417,8 +417,8 @@ The following are the core Debian mailing lists: &email-debian-devel;,
 &email-debian-policy;, &email-debian-user;, &email-debian-private;,
 &email-debian-announce;, and &email-debian-devel-announce;.  All
 developers are expected to be subscribed to at least
 &email-debian-policy;, &email-debian-user;, &email-debian-private;,
 &email-debian-announce;, and &email-debian-devel-announce;.  All
 developers are expected to be subscribed to at least

-&email-debian-private; and &email-debian-devel-announce;.  There are
-other mailing lists are available for a variety of special topics; see
+&email-debian-devel-announce;.  There are
+other mailing lists available for a variety of special topics; see

 <url id="&url-debian-lists-subscribe;"> for a list.  Cross-posting
 (sending the same message to multiple lists) is discouraged.
        <p>
 <url id="&url-debian-lists-subscribe;"> for a list.  Cross-posting
 (sending the same message to multiple lists) is discouraged.
        <p>


@@ -732,9 +732,9 @@ the header information from all those packages. The former are kept in the
 directory of the archive (because of backwards compatibility).
 
 
 directory of the archive (because of backwards compatibility).
 
 

-       <sect1>Stable, testing, unstable, and sometimes frozen
+       <sect1 id="sec-dists">Stable, testing, and unstable

        <p>
        <p>

-There is always a distribution called <em>stable</em> (residing in
+There are always distributions called <em>stable</em> (residing in

 <tt>dists/stable</tt>), one called <em>testing</em> (residing in
 <tt>dists/testing</tt>), and one called <em>unstable</em> (residing in
 <tt>dists/unstable</tt>). This reflects the development process of the
 <tt>dists/stable</tt>), one called <em>testing</em> (residing in
 <tt>dists/testing</tt>), and one called <em>unstable</em> (residing in
 <tt>dists/unstable</tt>). This reflects the development process of the


@@ -750,48 +750,46 @@ sometimes ``unstable.''
        <p>
 Packages get copied from <em>unstable</em> to <em>testing</em> if they
 satisfy certain criteria. To get into <em>testing</em> distribution, a
        <p>
 Packages get copied from <em>unstable</em> to <em>testing</em> if they
 satisfy certain criteria. To get into <em>testing</em> distribution, a

-package needs to be in the archive for two weeks and not have any release
-critical bugs. After that period, it will propagate into <em>testing</em>
-as soon as anything it depends on is also added. This process is automatic.
+package needs to be in the archive for two weeks and not have any
+release critical bugs. After that period, it will propagate into
+<em>testing</em> as soon as anything it depends on is also added. This
+process is automatic.  You can see some notes on this system as well
+as <tt>update_excuses</tt> (describing which packages are valid
+candidates, which are not, and why not) at <url
+id="&url-testing-maint;">.

        <p>
 After a period of development, once the release manager deems fit, the
        <p>
 After a period of development, once the release manager deems fit, the

-<em>testing</em> distribution is renamed to <em>frozen</em>. Once
-that has been done, no changes are allowed to that distribution except
-bug fixes; that's why it's called ``frozen.''  After another month or
-a little longer, depending on the progress, the <em>frozen</em> distribution
+<em>testing</em> distribution is frozen, meaning that the policies
+which control how packages move from <em>unstable</em> to testing are
+tightened.  Packages which are too buggy are removed.  No changes are
+allowed into <em>testing</em> except for bug fixes.  After some time
+has elapsed, depending on progress, the <em>testing</em> distribution

 goes into a `deep freeze', when no changes are made to it except those
 goes into a `deep freeze', when no changes are made to it except those

-needed for the installation system. This is called a ``test cycle'', and it
-can last up to two weeks. There can be several test cycles, until the
-distribution is prepared for release, as decided by the release manager.
-At the end of the last test cycle, the <em>frozen</em> distribution is
-renamed to <em>stable</em>, overriding the old <em>stable</em> distribution,
-which is removed at that time.
+needed for the installation system.  This is called a ``test cycle'',
+and it can last up to two weeks. There can be several test cycles,
+until the distribution is prepared for release, as decided by the
+release manager.  At the end of the last test cycle, the
+<em>testing</em> distribution is renamed to <em>stable</em>,
+overriding the old <em>stable</em> distribution, which is removed at
+that time (although they can be found at <tt>archive-host;</tt>).

        <p>
 This development cycle is based on the assumption that the
 <em>unstable</em> distribution becomes <em>stable</em> after passing a
        <p>
 This development cycle is based on the assumption that the
 <em>unstable</em> distribution becomes <em>stable</em> after passing a

-period of testing as <em>frozen</em>.  Even once a distribution is
-considered stable, a few bugs inevitably remain &mdash that's why the stable
-distribution is updated every now and then. However, these updates are
-tested very carefully and have to be introduced into the archive
-individually to reduce the risk of introducing new bugs.  You can find
-proposed additions to <em>stable</em> in the <tt>proposed-updates</tt>
-directory.  Those packages in <tt>proposed-updates</tt> that pass
-muster are periodically moved as a batch into the stable distribution
-and the revision level of the stable distribution is incremented
-(e.g., `1.3' becomes `1.3r1', `2.0r2' becomes `2.0r3', and so forth).
+period of being in <em>testing</em>.  Even once a distribution is
+considered stable, a few bugs inevitably remain &mdash that's why the
+stable distribution is updated every now and then. However, these
+updates are tested very carefully and have to be introduced into the
+archive individually to reduce the risk of introducing new bugs.  You
+can find proposed additions to <em>stable</em> in the
+<tt>proposed-updates</tt> directory.  Those packages in
+<tt>proposed-updates</tt> that pass muster are periodically moved as a
+batch into the stable distribution and the revision level of the
+stable distribution is incremented (e.g., `1.3' becomes `1.3r1',
+`2.0r2' becomes `2.0r3', and so forth).

        <p>
 Note that development under <em>unstable</em> continues during the
 ``freeze'' period, since the <em>unstable</em> distribution remains in
        <p>
 Note that development under <em>unstable</em> continues during the
 ``freeze'' period, since the <em>unstable</em> distribution remains in

-place when the <em>testing</em> is moved to <em>frozen</em>.
-Another wrinkle is that when the <em>frozen</em> distribution is
-offically released, the old stable distribution is completely removed
-from the Debian archives (although they do live on at
-<tt>archive-host;</tt>).
-       <p>
-In summary, there is always a <em>stable</em>, a <em>testing</em> and an
-<em>unstable</em> distribution available, and a <em>frozen</em> distribution
-shows up for a couple of months from time to time.
-
+place in parallel with <em>testing</em>.

 
        <sect1>Experimental
          <p>
 
        <sect1>Experimental
          <p>


@@ -865,9 +863,9 @@ determined by their code names and not their release status (e.g.,
 `slink').  These names stay the same during the development period and
 after the release; symbolic links, which can be changed easily,
 indicate the currently released stable distribution.  That's why the
 `slink').  These names stay the same during the development period and
 after the release; symbolic links, which can be changed easily,
 indicate the currently released stable distribution.  That's why the

-real distribution directories use the <em>code names</em>, while symbolic
-links for <em>stable</em>, <em>testing</em>, <em>unstable</em>, and
-<em>frozen</em> point to the appropriate release directories.
+real distribution directories use the <em>code names</em>, while
+symbolic links for <em>stable</em>, <em>testing</em>, and
+<em>unstable</em> point to the appropriate release directories.

 
 
     <chapt id="upload">Package uploads
 
 
     <chapt id="upload">Package uploads


@@ -1004,16 +1002,10 @@ The <tt>Distribution</tt> field, which originates from the first line of
 the <file>debian/changelog</file> file, indicates which distribution the
 package is intended for.
          <p>
 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', and `experimental'. Normally, packages are uploaded into
+There are three possible values for this field: `stable', `unstable',
+and `experimental'. Normally, packages are uploaded into

 <em>unstable</em>.
          <p>
 <em>unstable</em>.
          <p>

-These values can be combined, but only a few combinations make sense.
-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 uploading to
-<em>frozen</em>.
-         <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).
 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).


@@ -1023,6 +1015,7 @@ upload to <em>stable</em>.
 It never makes sense to combine the <em>experimental</em> distribution
 with anything else.
 
 It never makes sense to combine the <em>experimental</em> distribution
 with anything else.
 

+<!-- 

          <sect2 id="upload-frozen">Uploading to <em>frozen</em>
            <p>
 The Debian freeze is a crucial time for Debian.  It is our chance to
          <sect2 id="upload-frozen">Uploading to <em>frozen</em>
            <p>
 The Debian freeze is a crucial time for Debian.  It is our chance to


@@ -1063,6 +1056,8 @@ product.  There is little correlation between the severity of the
 original bug fixed and the severity of the bug newly introduced by the
 fix.
 
 original bug fixed and the severity of the bug newly introduced by the
 fix.
 

+ -->
+

 
          <sect2 id="upload-stable">Uploading to <em>stable</em>
            <p>
 
          <sect2 id="upload-stable">Uploading to <em>stable</em>
            <p>


@@ -1251,7 +1246,7 @@ send those announcements (check its documentation and look for
 If a package is released with the <tt>Distribution:</tt> set to
 `stable', the announcement is sent to &email-debian-changes;.  If a
 package is released with <tt>Distribution:</tt> set to `unstable',
 If a package is released with the <tt>Distribution:</tt> set to
 `stable', the announcement is sent to &email-debian-changes;.  If a
 package is released with <tt>Distribution:</tt> set to `unstable',

-`experimental', or `frozen' (when present), the announcement will be
+or `experimental', the announcement will be

 posted to &email-debian-devel-changes; instead.
        <p>
 The <prgn>dupload</prgn> program is clever enough to determine
 posted to &email-debian-devel-changes; instead.
        <p>
 The <prgn>dupload</prgn> program is clever enough to determine


@@ -1378,7 +1373,7 @@ quality patches and bug reports.
       <sect id="nmu-when">When to do a source NMU
        <p>
 Guidelines for when to do a source NMU depend on the target
       <sect id="nmu-when">When to do a source NMU
        <p>
 Guidelines for when to do a source NMU depend on the target

-distribution, i.e., stable, unstable, or frozen.  Porters have
+distribution, i.e., stable, unstable, or experimental.  Porters have

 slightly different rules than non-porters, due to their unique
 circumstances (see <ref id="source-nmu-when-porter">).
        <p>
 slightly different rules than non-porters, due to their unique
 circumstances (see <ref id="source-nmu-when-porter">).
        <p>


@@ -1390,12 +1385,12 @@ maintainer cannot provide a fixed package fast enough or if he/she
 cannot be reached in time, a security officer may upload a fixed
 package (i.e., do a source NMU).
        <p>
 cannot be reached in time, a security officer may upload a fixed
 package (i.e., do a source NMU).
        <p>

-During the release freeze (see <ref id="upload-frozen">), NMUs which
-fix serious or higher severity bugs are encouraged and accepted.
-Even during this window, however, you should endeavor to reach the
-current maintainer of the package; they might be just about to upload
-a fix for the problem.  As with any source NMU, the guidelines found
-in <ref id="nmu-guidelines"> need to be followed.
+During the release cycle (see <ref id="sec-dists">), NMUs which fix
+serious or higher severity bugs are encouraged and accepted.  Even
+during this window, however, you should endeavor to reach the current
+maintainer of the package; they might be just about to upload a fix
+for the problem.  As with any source NMU, the guidelines found in <ref
+id="nmu-guidelines"> need to be followed.

        <p>
 Bug fixes to unstable by non-maintainers are also acceptable, but only
 as a last resort or with permission.  Try the following steps first,
        <p>
 Bug fixes to unstable by non-maintainers are also acceptable, but only
 as a last resort or with permission.  Try the following steps first,


@@ -1704,11 +1699,16 @@ Porters doing a source NMU generally follow the guidelines found in
 the wait cycle for a porter's source NMU is smaller than for a
 non-porter, since porters have to cope with a large quantity of
 packages.
 the wait cycle for a porter's source NMU is smaller than for a
 non-porter, since porters have to cope with a large quantity of
 packages.

-         <p>

 Again, the situation varies depending on the distribution they are
 Again, the situation varies depending on the distribution they are

-uploading to.  Crucial fixes (i.e., changes need to get a source
+uploading to.
+
+<!-- 
+FIXME: commented out until I can work out how to upload to testing directly
+
+  Crucial fixes (i.e., changes need to get a source

 package to compile for a released-targeted architecture) can be
 uploaded with <em>no</em> waiting period for the `frozen' distribution.
 package to compile for a released-targeted architecture) can be
 uploaded with <em>no</em> waiting period for the `frozen' distribution.

+ -->

          <p>
 However, if you are a porter doing an NMU for `unstable', the above
 guidelines for porting should be followed, with two variations.
          <p>
 However, if you are a porter doing an NMU for `unstable', the above
 guidelines for porting should be followed, with two variations.