From: joy Date: Thu, 18 Oct 2001 00:17:43 +0000 (+0000) Subject: updated the section about experimental (better late than never) X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=3087364ed9f51b0272ed7e7cb2d498b39702f6e4;ds=sidebyside updated the section about experimental (better late than never) git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1272 313b444b-1b9f-4f58-a734-7bb04f332e8d --- diff --git a/developers-reference.sgml b/developers-reference.sgml index f45f7f6..7249fef 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -784,41 +784,42 @@ shows up for a couple of months from time to time. Experimental -

The experimental distribution is a specialty distribution. It is not a full distribution in the same sense as `stable' and `unstable' are. Instead, it is meant to be a temporary staging area for highly experimental software where there's a good chance that the -software could break your system. Users who download and install +software could break your system, or software that's just too unstable +even for the unstable distribution (but there is a reason to +package it nevertheless). Users who download and install packages from experimental are expected to have been duly warned. In short, all bets are off for the experimental distribution.

-Developers should be very selective in the use of the -experimental distribution. Even if a package is highly -unstable, it could still go into unstable; just state a -few warnings in the description. However, if there is a chance that -the software could do grave damage to a system, it might be better to -put it into experimental. -

+If there is a chance that the software could do grave damage to a system, +it is likely to be better to put it into experimental. For instance, an experimental compressed file system should probably go -into experimental. A new, beta, version of some software -which uses completely different configuration might go into -experimental at the maintainer's discretion. New software -which isn't likely to damage your system can go into -unstable. If you are working on an incompatible or complex -upgrade situation, you can also use experimental as a staging -area, so that testers can get early access. -

-However, using experimental as a personal staging area is not -always the best idea, especially with transient packages. For -example, you cannot delete packages which have been uploaded to -experimental on your own; that must be done by the Debian -archive maintainers. An alternative is to use your personal web space -on klecker.debian.org, a.k.a. people.debian.org. +into experimental. +

+Whenever there is a new upstream version of a package that introduces new +features but breaks a lot of old ones, it should either not be uploaded, or +be uploaded to experimental. A new, beta, version of some software +which uses completely different configuration can go into +experimental, at the maintainer's discretion. If you are working +on an incompatible or complex upgrade situation, you can also use +experimental as a staging area, so that testers can get early +access. +

+Some experimental software can still go into unstable, with a few +warnings in the description, but that isn't recommended because packages +from unstable are expected to propagate to testing and +thus to stable. +

+New software which isn't likely to damage your system can go directly into +unstable. +

+An alternative to experimental is to use your personal web space +on people.debian.org (klecker.debian.org). Release code names