Thought - Delay auto-updates of software to reduce downtime

[Alexander Jacob Tsykin]

On Friday 22 September 2006 04:07, Shawn McMahon wrote:
> 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?
>
of course not, but actually what the hypothetical situation was was delaying 
the fix until it has been tested and sending them cut and paste while it is 
being tested. This is much worse than just giving them access to the patched 
package straight away.
> 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.
>
thank you for pointing out the obvious. Unfortunately, Ubuntu is not aimed at 
the sort of user who can do anything about this. Even assuming that they 
would knot who to send an email to, which is in itself a huge assumption, and 
even assuming that somebody has time to reply to literally thousands of 
emails a day, which is even bigger, it is likely they will not know enough to 
send an email report which actually says something useful, allowing the 
person on the other end to send out a fix. Instead, they will say something 
like "my computer's not working" because X refuses to start, or "my computer 
is slow" because for some reason the ethernet driver is slow giving slow 
access to the internet, and then how are you meant to help them. Think about 
the practicalities of an idea please. It is not enough to say that "we have 
this solution," Ubuntu must provide a solution which works for it starget 
market, which is not techno geeks. While I use the command line regularly 
formany things including compiling from source, I am not the target market of 
Ubuntu and should not be treated as such.
> 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.
>
not at all. I said that the updates should not be delayed. That way people 
won't be deprived of the fix before it is %100 tested, even though it might 
introduce bugs of its own. That was the debate. Try to follow before 
participating, and please refrain from making this personal. That can be seen 
in almost every prior email in this thread as well as in the subject line. If 
nothing else, make the minimal effort required to read that.
> 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.
>
The command line is never easier. Think about it, you are telling them to do 
something completely outside their comfort zone which they don't understand, 
probably based on insufficient information. Is that a joke?

More to the point, you will be telling them to download a .deb for a package 
which they probably haven't told you. You don't know their architecture. You 
can't really help them because you have no information. This is not a 
solution suitable for he vast number of people. The problems are so obvious I 
can't believe you can't see them.
> 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 lack so much confidence in the fixes, then don't download them, you 
have the option, but I always update straight away, and even in Edgy, the 
fixes rarely seem to introduce new bugs. In daper the problem seems to be 
nonexistent. Better to make sure the fixes are of a sufficient quality before 
posting them, and if they introduce a new bug, fix that too than trying to 
delay fixes and apply completely insufficient solutions to the problems this 
will cause.
> 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.
>
And you think that will scare them less? The problem is not only the command 
line. "linux for human beings" which prides itself on being easy to use, 
should not be forcing people to make unsupported changes to their system 
manually. It should, if anything, remove the need. This i not a solution 
which is suitable for the problem, which really should be obvious.

The idea of delaying auto-updates is not in itself inherently bad. It can even 
be useful. But before it is implemented, some problems with it must be fixed 
first. It is not enough to have someone email around unsupported and possibly 
themselves buggy fixes. And then, lets say the bug is with a crucial package 
and you tell them to downgrade it, say openoffice.org. Then all the other 
packages which are part of the suite will have to be downgraded to. All the 
dictionary packages, all the various programs that are part of the suite. In 
short, you nearly break their system. And in the unlikely chance they manage 
to do all this without completely destroying the usefulness of their system 
for all intents and purposes, because if openoffice doesn't work, then they 
are in trouble, they have no productivity applications and they will abandon 
Ubuntu, (remember we are talking about a non-technically inclined user), then 
their system will immediately start pestering them to make upgrades, and do 
you think for a minute they will know what to do? No.

Another obvious question: who is to send out these email? Are you willing to 
volunteer. If you are not, and I doubt anybody else wants to, then canonical 
would have to hire somebody for each language in which Ubuntu is widely used. 
Do you think the company will do this? Think again.

Please think about suggestions before submitting them. This would be a 
wonderful idea if the problems could be ironed out, but at the moment it 
seems impractical.

Sasha