* Andrew Pollock (apollock@debian.org) wrote: > 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... We always have to be careful with things like that, since stable is *stable*... it should not really change, except to address critical issues. Not that I disagree with your proposal. I think that some value in updating these packages, and for packages such as spamassassin and snort the case could be made that updating them would be security updates, particularly in the case of snort. Also those two packages really contain rule sets that could be packaged separately and updated, while leaving the core code unchanged. That would probably be the least surprising thing, and the least likely to cause bugs, but would still be a lot of work and testing. Another package I think would be on the list might be gaim. If msn or yahoo changes their protocol then it becomes rather broken. This one would be very difficult to handle in most cases... new version could introduce new bugs, and backports could be really tough. -- Eric Dorland <eric.dorland@mail.mcgill.ca> ICQ: #61138586, Jabber: hooty@jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ ------END GEEK CODE BLOCK------
Attachment:
signature.asc
Description: Digital signature