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

Re: Proposed change to debian release system



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




Reply to: