[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tentative Proposal: Regarding experimental use

On Fri, Jun 09, 2000 at 04:15:42PM -0400, Franklin Belew wrote:
> 1> All completely new packages are required to go into experimental for no
>    less than 30 days as a trial period.
> 2> All new maintainers must put their packages into experimental for no 
>    less than 30 days as a trial period.
> 3> All packages which change maintainers will be put into experimental
>    for a 30 day trial period
> 4> When a packages is orphaned, it stays in the main archive for 30 days
>    If no one has adopted it within this period, it will be removed from the
>    Archive.
> 5> ALL essential or required packages will go into experimental for testing
>    for 30 days before allowed in the archive
> 6> All sponsored packages will be put into experimental for a trial period
>    of no less than 30 days
> This tentative proposal will be dropped completely if a package pool proposal 
> is made with an implementation and documentation.

   There is an early package pool implementation at

   A variation of part 4 of this proposal is already supported by the pclean
process.  Once packages are no longer part of any distribution (eg.
experimental, bleeding, unstable,stable,...) a time-to-destruction is set on
the package, and if it is not reset by adding it to a distribution the
package will be deleted from the archive.   

   With a package pool in place using experimental or bleeding for
changes-of-management is a good idea, and promotion to unstable/testing
should in general have a time delay and automatically be blocked by
important new bugs (subject to manual override by distribution managers).
The unstable/testing selection algorithms have not been coded yet.

   SQL gurus are invited to contribute queries that accomplish any of the
incomplete tasks.  It usually takes me a few days of fairly intense
concentration to come up with a way to express these relationships.  Even
bleeding (roughly what our current unstable is, but with automatic new
package addition) took most of a page to express in a simple DELETE and
INSERT transaction, and close to a week to get to it's current form.  More
complex distributions will almost certainly be partially procedural. 
stable/ and deep-freeze are completely manual, so they need no additional
code to support.

Reply to: