Thought - Delay auto-updates of software to reduce downtime

[Eric Dunbar]

On 19/09/06, Brandon Holtsclaw <imbrandon at kubuntu.org> wrote:
> On Monday 18 September 2006 22:14, Eric Dunbar wrote:
> > One way to avoid that is to have staggered or delayed auto-updates,
> > except for highly critical (and well-tested) security updates. I'm
> > thinking two weeks, maybe more, along with a slightly random element
> > built in to lower loads on update servers. The delay can be reduced or
> > increased through a simple preference setting.
>
> While this is a sounds to be a good idea I can see a couple of issues that
> would make this do more harm than good, let me explain a bit ...
>
> First this would make support ( on the phone , irc, commercial, bugreports,
> etc etc etc ) a nightmare, imagine this senerio ( and wouldent be to
> uncommon ) ...
>
> Support1: What version of <package> are you running ?
>
> Joe: up-to-date as of NN-NN-NNNN, I just ran all my updates
>
> Support1 <noting to self that dosent mean they have the latest package>: can
> you tell me the version number by running "<package> -v " ?
>
> Joe: Version blah_134-0ubuntu2

I agree that it _could_ be a problem if updates were coming
back-to-back-to-back without any breaks (a very very bad thing
anyway). However, in practice I think such a scenario would actually
be _uncommon_.

If a problem crops up, support agents will start to receive calls
fairly soon after the problem appears (i.e. after an update/new
version comes out). This means calls will peak soon thereafter and the
support agent will probably give the reply: "We are working on a fix.
In the meantime..." By the time the bug fix is released the calls will
likely have tapered off and the scenario would affect a miniscule
portion of people who are affected (think of the bell curve and
standard deviations)

> 1) Now how do you tell a user there is a fix in the archives but they cant
> have it becouse the updates are stagered

There's no reason there can't be an 'Update now' button.

Mac OS X does it. I'm sure Ubuntu does it already (I just don't know
where since I only ever use Synaptic to do a forced update ;-).

> 2) once the "users" or most anyone finds out they can change this setting they
> have been branded to "always run the latest stable" and thus will lower the
> update threshhold to the minimum right away
>
> 3) #2 would then create a false sense of "cushion" for those that push the
> updates thinking it will potentialy only affect N users if something is bad
> but in reality 80% or better has lowered their threshold to get the update
> right away.

I don't think it'll change the developers' fault-tolerance much, if at all!

The reality is that 80% (a significant portion, anyway) of the people
will NOT have lowered their two-week threshold (assuming that as
default). Most users don't change default settings (for the most part,
I don't) so I don't see much of a reason that most users would do this
(and, those who have the technical know-how to change to early
auto-update will also have the technical know-how to handle some
problems).

Plus, package maintainers will have a sense of how quickly updates are
applied -- they can see when people download their updates.

If 70% of updates are downloaded within the first three days of a
release (for e.g.) they'll know that most people have reduced the date
threshold. If the update downloads are staggered evenly over two weeks
(with a slight spike on the first day or two) then they'll know how
many people haven't change the defaults.

In OS X I used to apply updates immediately if there was a bug fix I'd
been waiting for but nowadays I ignore updates until my auto-update
does its work since OS X is so absolutely rock-solid-stable there's
never any need to be running the latest version.

The same psychology should apply to most Ubuntu/Linux users as well
since Ubuntu/Linux is now stable enough that updates are incremental,
EVEN security updates (yes, I know that's blasphemy, but security
updates can be just as disruptive as 'regular' updates).

> Now I dont have all the right answers, and this idea does look to be
> promising , but as noted some things would have to be worked out. I think a
> better solution is going to be plain and simple QA with the updates, AND more
> use of the <stable>-proposed pockets , where a user has to turn the early
> updates ON and can be officialy not-supported etc etc etc, like we seen with
> the early oo.o updates
>
> Just my 0.02c

There certainly would be problems with what I proposed.

QA with the updates really doesn't help. How many people out there
read the fine print of update READMEs?!!!! I rarely do, and only if I
suspect updating the package could muck something up (and, I have the
computer literacy to know what packages could muck things up and which
ones are extraneous).

PS I like the idea of an expanded beta audience. That is certainly a
good first hump but it does cost. STABILITY should come before all
other considerations. Having a buffer between release and adoption by
90% of user base is a good idea. Another thing that could happen is to
have an 'urgent' update flag which would force systems to download a
security patch (or an important bug-fix) immediately. The client
Ubuntu computers would check the update server every day, but they'd
only download/notify their users of non-urgent updates once every week
(or two weeks).

PS^2 There's no reason the delay couldn't be two or three days instead
of a week. This would allow show-stopper bugs to be detected (i.e.
kernel panic on boot or load of GNOME) before they spread too far
(much like the one earlier in the year).

PS^3 I'm curious to know how dapper-proposed implemented things (as
per Tollef Fog Heen)

Here's my 0.25c (inflation ;-)