From c94af677b6d9e6158f0bfdca124c493eef3050a6 Mon Sep 17 00:00:00 2001 From: aph Date: Sun, 24 Feb 2002 19:13:49 +0000 Subject: [PATCH] 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 --- common.ent | 2 + developers-reference.sgml | 118 +++++++++++++++++++------------------- 2 files changed, 61 insertions(+), 59 deletions(-) diff --git a/common.ent b/common.ent index 61d5ae1..fd045b2 100644 --- a/common.ent +++ b/common.ent @@ -63,6 +63,8 @@ + + diff --git a/developers-reference.sgml b/developers-reference.sgml index 2d7a1d5..0345fa4 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -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 for a list. Cross-posting (sending the same message to multiple lists) is discouraged.

@@ -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). - Stable, testing, unstable, and sometimes frozen + Stable, testing, and unstable

-There is always a distribution called stable (residing in +There are always distributions called stable (residing in dists/stable), one called testing (residing in dists/testing), and one called unstable (residing in dists/unstable). This reflects the development process of the @@ -750,48 +750,46 @@ sometimes ``unstable.''

Packages get copied from unstable to testing if they satisfy certain criteria. To get into testing 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 testing -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 +testing 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 update_excuses (describing which packages are valid +candidates, which are not, and why not) at .

After a period of development, once the release manager deems fit, the -testing distribution is renamed to frozen. 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 frozen distribution +testing distribution is frozen, meaning that the policies +which control how packages move from unstable to testing are +tightened. Packages which are too buggy are removed. No changes are +allowed into testing except for bug fixes. After some time +has elapsed, depending on progress, the testing 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 frozen distribution is -renamed to stable, overriding the old stable 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 +testing distribution is renamed to stable, +overriding the old stable distribution, which is removed at +that time (although they can be found at archive-host;).

This development cycle is based on the assumption that the unstable distribution becomes stable after passing a -period of testing as frozen. 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 stable in the proposed-updates -directory. Those packages in proposed-updates 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 testing. 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 stable in the +proposed-updates directory. Those packages in +proposed-updates 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).

Note that development under unstable continues during the ``freeze'' period, since the unstable distribution remains in -place when the testing is moved to frozen. -Another wrinkle is that when the frozen distribution is -offically released, the old stable distribution is completely removed -from the Debian archives (although they do live on at -archive-host;). -

-In summary, there is always a stable, a testing and an -unstable distribution available, and a frozen distribution -shows up for a couple of months from time to time. - +place in parallel with testing. Experimental

@@ -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 code names, while symbolic -links for stable, testing, unstable, and -frozen point to the appropriate release directories. +real distribution directories use the code names, while +symbolic links for stable, testing, and +unstable point to the appropriate release directories. Package uploads @@ -1004,16 +1002,10 @@ The Distribution field, which originates from the first line of the debian/changelog file, indicates which distribution the package is intended for.

-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 unstable.

-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 -frozen, you would set the distribution to `frozen unstable'. -See for more information on uploading to -frozen. -

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 stable. It never makes sense to combine the experimental distribution with anything else. + + Uploading to stable

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

The dupload program is clever enough to determine @@ -1378,7 +1373,7 @@ quality patches and bug reports. When to do a source NMU

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 ).

@@ -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).

-During the release freeze (see ), 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 need to be followed. +During the release cycle (see ), 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 need to be followed.

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. -

Again, the situation varies depending on the distribution they are -uploading to. Crucial fixes (i.e., changes need to get a source +uploading to. + +

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