>
> That is what stable is about: not changing, or when change is absolutely
> necessary, changing as little as possible. A hot new Firefox release may
> seem sexy to a Linux enthusiast, but to the novice, or to the corporate IS
> administrator, it means risk.
>
> --
> - mdz
Stable: b. Not subject to mental illness or irrationality
c. Maintaining equilibrium; self-restoring: a stable aircraft.
We can pick and choose our definitions all day, but it does not change
the actual problem.
As you can see in the subject, the OP understands the policy, but believes
it should be changed. As an IS administrator with over 75 debian systems
supported across 3 geographic locations, an old and broken release with
Known Vulnerablities means RISK. A new version of a well maintained and
developed piece of software may all so have risks, but they are smaller. I
can choose when and where to allow it in after sufficient testing. Even
backporting the security fixes runs the chance that something will be
broken in the proccess. Leave the original version in "stable" but put the
new version and any cascading packages in security. Those who Must have a
package list fixed in amber can keep their system offline and not put the
security line in their sources- as security will require changes at some
level.
I support introducting new packages when older versions can not be
realisticly maintained with backported security fixes.
--
David Ehle
Computing Systems Manager
CAPP CSRRI BIOCAT
rm 077
LS Bld. IIT Main Campus
Chicago IL 60616
[EMAIL PROTECTED]
312-567-3751
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
