Re: A `second' to the ``package pool''
"Christopher W. Curtis" <ccurtis@aet-usa.com> writes:
> Hello,
...
> adding another level might allow this to work better. Instead of
> the seemingly three-tiered design, I would like to suggest a
> four-tier:
>
> stable (release)
> frozen
> semistable
> unstable
Sounds good. Stable should be whats pressed on CDs by distributors.
> I should also say that I'm not a Debian Developer, so feel free to
> take with a grain of salt -- but it seems to me that a good
> development scheme would be to upload all new packages into unstable
> where things like the broken fsck can get hashed out without
> affecting so many people. Packages live in this staging area for
> ``x'' time (72 hours?) and if they are not updated and no bugs have
> been filed against them, they are automatically upgraded into the
> "semistable" area. This is where I would see "cutting edge" users
> apt-get'ting from, with most (all?) developers updating from
> unstable.
I think the popularity-contest package should be used to see that a
package has been in use without bug reports coming in.
A criteria when to move should be the amount of useage of a
package. Since popularity-contest reports once a night (normaly) it
would be the same when one person uses the package each day over a
week or when 7 people test it once. When 20 (for example) useage
reports are collected by the popularity-contest server, the package
could be moved to semistable.
> After some time (1 month?) the packages in semistable can be opted
> up to 'frozen'. This scheme could use the same for the original
Here again I would use the popularity-contest package, but also a time
limit. Say 1 month old and at least 100 useage reports. Or multiply
useage by time (in days) and make the limit 1000-10000.
May the Source be with you.
Goswin
Reply to: