On Sat, Dec 13, 2003 at 03:20:27PM +0000, Scott Minns wrote: > Hiya all, > First of all let me introduce myself, my name is Scott Minns, i'm a > debian user, not a developer. That most likely makes you question why > i'm using thins mailing list at all, let alone having the gall to > propose altering a well established testing and release system. > > Here is my proposal and I would like to hear your thoughts on it, In > addition to the present releases- stable, testing and unstable. We add a > release called current.
[snip] What you propose is probably technically difficult to actually achieve, due to dependencies, and would, as has already been pointed out, effectively mean there are two "stable" distributions running around. I've been musing over a proposal for a while, which your email makes me want to raise now... I'd like to propose some changes to the stable release policy (ps it would be nice if the policy is linked from http://www.debian.org/releases/stable/). I'd like for certain packages to be classed as "perishable", i.e. they become more or less useless with age. How packages should be classsed as such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?), but to provide some examples: * spamassassin * snort could be considered perishable because their effectiveness is reduced over time. Such classed packages should be allowed to be updated in stable, I feel. Of course, it could be argued that any package is perishable, and thus this whole thing becomes a moot point... The exact policy on what and how they can be updated needs to be debated, and of course the whole thing would need the Stable Release Manager's blessing. It also makes for more work for both the Stable Release Manager and the Security Team though, as there would be multiple versions of a package that could potentially require a security update. This makes the proposal unattractive, but coming back to the Social Contract, our first priority should be to our users, so if an 18 month old stable distribution is not serving our users needs adequately, and we can't (in the short term) shorten our release cycle, then perhaps this is a middle ground that can be explored further... This proposal is a tad premature in that I hadn't thought it through in as much depth as I'd have liked to have before floating it, but I felt the original email was a good catalyst for getting it out there... Andrew