On Wed, Mar 21, 2001 at 12:19:02AM -0500, Branden Robinson wrote:
> On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> > Summary:
> > History:
> > Technical reasoning:
> > Issues:
> > Caveats:
> 
> But nowhere did you have the actual text of a policy change.  This is
> needed.
> 
> Please write one up and I'll second it.

Right, here it is.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'
diff -urN debian-policy-3.5.2.0.orig/policy.sgml 
debian-policy-3.5.2.0/policy.sgml
--- debian-policy-3.5.2.0.orig/policy.sgml      Sun Feb 18 09:37:35 2001
+++ debian-policy-3.5.2.0/policy.sgml   Wed Mar 21 12:44:48 2001
@@ -1400,8 +1400,8 @@
 
          <p>
            In a <tt>.changes</tt> file or parsed changelog output
-           this contains the (space-separated) name(s) of the
-           distribution(s) where this version of the package should
+           this contains the name of the
+           distribution where this version of the package should
            be or was installed.  Distribution names follow the rules
            for package names.  (See <ref id="f-Package">).
          </p>
@@ -1434,15 +1434,23 @@
                    </p>
                  </item>
 
-                 <tag><em>frozen</em></tag>
+                 <tag><em>testing</em></tag>
                  <item>
                    <p>
-                     From time to time, the <em>unstable</em>
-                     distribution enters a state of `code-freeze' in
-                     anticipation of release as a <em>stable</em>
-                     version. During this period of testing only
-                     fixes for existing or newly-discovered bugs will
-                     be allowed.
+                     Testing is a psuedo distribution that is a
+                     culmination of the previous <em>stable</em> release
+                     with select packages from <em>unstable</em> applied
+                     to it. The packages have to meet certain criteria in
+                     order to migrate from <em>unstable</em> into
+                     <em>testing</em>. Some of these criteria include being
+                     compiled on all supported architectures, no open
+                     release critical bugs and no dependencies on
+                     packages that are not in <em>testing</em> already
+                     (which may fail some of these criteria). Also, there
+                     is a time constraint before migration. Note, you cannot
+                     upload directly to <em>testing</em> as you can with
+                     <em>stable</em> and <em>unstable</em>. This distribution
+                     is the base for the next planned release.
                    </p>
                  </item>
 
@@ -1493,12 +1501,26 @@
                      Distribution.</p>
                  </item>
 
-               </taglist> You should list <em>all</em> distributions that
-               the package should be installed into. Except in unusual
-               circumstances, installations to <em>stable</em> should also
-               go into <em>frozen</em> (if it exists) and
-               <em>unstable</em>. Likewise, installations into
-               <em>frozen</em> should also go into <em>unstable</em>.
+               </taglist>
+               You should list <em>only</em> the distribution that the
+               package was compiled for. Do not upload to multiple
+               distributions. Currently it is only possible to upload to
+               <em>stable</em>, <em>unstable</em> or <em>experimental</em>.
+               If an upload needs to go to both <em>stable</em> and
+               <em>unstable</em>, then they must be uploaded seperately,
+               and with different version numbers, the <em>stable</em>
+               version being less than the <em>unstable</em> one.
+               <p>
+               One example of this is if the current version of the
+               <em>stable</em> and <em>unstable</em> package is 1.2-1, then
+               a new upload can have 1.2-1.90 for <em>stable</em> and 1.2-2 for
+               <em>unstable</em>. Each should be compiled on that
+               particular distribution, so that it abides by the policy
+               of that distribution, so it will use the latest libraries
+               available on that distribution, and so it will be in sync with
+               what the autobuilders for the other architectures produce (they
+               always build on the latest version of a particular
+               distribution).
            </footnote>
          </p>
        </sect1>
@@ -1997,7 +2019,7 @@
        <p>
          That format is a series of entries like this:
          <example>
-           <var>package</var> (<var>version</var>) <var>distribution(s)</var>; 
urgency=<var>urgency</var>
+           <var>package</var> (<var>version</var>) <var>distribution</var>; 
urgency=<var>urgency</var>
 
            * <var>change details</var>
            <var>more change details</var>
@@ -2013,7 +2035,7 @@
        </p>
 
        <p>
-         <var>distribution(s)</var> lists the distributions where
+         <var>distribution</var> lists the distribution where
          this version should be installed when it is uploaded - it
          is copied to the <tt>Distribution</tt> field in the
          <tt>.changes</tt> file.  See <ref id="f-Distribution">.

Reply via email to