chiark / gitweb /
purge references to 'frozen' distribution, which doesn't exist anymore
authoraph <aph@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 24 Feb 2002 19:13:49 +0000 (19:13 +0000)
committeraph <aph@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 24 Feb 2002 19:13:49 +0000 (19:13 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1436 313b444b-1b9f-4f58-a734-7bb04f332e8d

common.ent
developers-reference.sgml

index 61d5ae1..fd045b2 100644 (file)
@@ -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-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">
index 2d7a1d5..0345fa4 100644 (file)
@@ -5,7 +5,7 @@
   <!-- 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 -->
@@ -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-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>
@@ -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).
 
 
-       <sect1>Stable, testing, unstable, and sometimes frozen
+       <sect1 id="sec-dists">Stable, testing, and unstable
        <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
@@ -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
-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
-<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
-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
-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
-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>
@@ -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
-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
@@ -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>
-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>
-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).
@@ -1023,6 +1015,7 @@ upload to <em>stable</em>.
 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
@@ -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.
 
+ -->
+
 
          <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',
-`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
@@ -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
-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>
@@ -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>
-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,
@@ -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.
-         <p>
 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.
+ -->
          <p>
 However, if you are a porter doing an NMU for `unstable', the above
 guidelines for porting should be followed, with two variations.