Thought - Delay auto-updates of software to reduce downtime
Shawn McMahon
smcmahon at eiv.com
Thu Sep 21 19:07:11 BST 2006
On Thu, 2006-09-21 at 07:58 +1000, Alexander Jacob Tsykin wrote:
> The issue is that all of that, particularly 2 and 4, would make it much more
> difficult for the user. Even downgrading you have to do manually via dpkg,
> something most users do not know how to do. This would be forcing them to the
> command line, comething which really should be avoided.
The hypothetical situation you're discussing is this, unless I've gotten
offtrack somehow:
A recent update has broken something for a small number of users. We
have a fix, but we haven't finished testing it yet. There is no
workaround they know of that enables them to continue doing something
important enough to them that they've reported this problem and asked
for help. We may or may not have a workaround documented.
In that situation, you think that providing them with a cut-and-paste
method of continuing with their work makes things more difficult for
them than stuff just not working?
Yes, #2 (get it from upstream yourself) is awful. It's why we HAVE a
packaging system and a testing process. #4 (here's a workaround until
we have the fix) is something that ANY endeavor has to put up with,
unless we just go with #5 which I didn't list: "tough crap, you're stuck
with the problem until we test the fix". Which, BTW, is the case with
EVERY bug until somebody figures out a workaround and/or produces a
patch.
It seems, again, that you'll only be happy if we can produce 100%
bug-free software, or failing that, have fixes ready AND FULLY TESTED
within 30 seconds of the first bug report or support request.
As for avoiding the command line, OK, so don't tell them a wget and dpkg
sequence; give them an URL to click on to download the updated or
downgraded package, and instructions on how to use Synaptic or the GDebi
stuff we've got for Nautilus to deal with packages directly. The
command line is much easier for this task if you are
cutting-and-pasting, but if you insist on inefficiency because it's
prettier that's doable too.
If we just tell every person with a problem "here, change your system to
shove all sorts of partially-tested crap over all your packages, so you
can get this one fix more quickly this one time", we're not helping
them; we're breaking more systems.
If you really, really just HATE the idea of somebody spending 30 seconds
cutting and pasting a couple of commands into a terminal window to do a
very uncommon activity, you could write something to fix it. A patch to
GDebi to give it some checkboxes or prompts "this is older than the one
you have installed; are you sure?" would do the trick. Might even be
able to configure things so that Firefox downloads of a .deb file
automatically fire up your improved GDebi. Then all it would take is a
single click of an URL to downgrade or upgrade a package. This is your
itch; scratch it.
--
Shawn McMahon |
EIV Consulting | Peace is a symptom of victory.
http://www.eiv.com |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/sounder/attachments/20060921/910c2ee0/attachment.pgp
More information about the sounder
mailing list