"Mark C. Langston" <mark(_at_)bitshift(_dot_)org> wrote:
They upgrade laptops regularly. So there's already an existing
model for deploying software upgrades. Wait 2-3 years, and deployment
will have reached the majority of users.
...and for those people that must wait a year, or two, or three, before
email is functional again?
They will have incentive to upgrade sooner.
When a service that many view as fundamental, such as email, stops
functioningi as deployed, trickling out a fix isn't seen as an
appropriate response.
It's already stopped functioning properly. And you're confusing the
design of a fix with it's deployment (or "trickling out"). We
shouldn't throw away designs simply because some people will deploy it
slowly. That's their problem.
My original comment on the 2-3 year deployment was that it was an
UPPER bound on deployment time. After 2-3 years, a large number of
people will have upgraded software, through the simple expedient of
upgrading their systems. People who want it deployed sooner have
incentive to do so, and can choose to do so.
For that reason, it'd be better to come up with a recommendation whose
impact is largely, or completely, server-side, and transparent to the
client and end-users.
Such as...?
This is the problem I've seen on ASRG for over a year now.
"Solution X doesn't satisfy criteria A, so we should wait for a
solution which does satisfy it". But no one proposes such a system.
After a year of this, that argument starts to look like a polite way
of refusing to deploy anything, ever.
Alan DeKok.