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
http://master.debian.org/~dld/pool/
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: