On Wed, Jun 17, 2009 at 12:51 AM, mac_v <drkvi-a@xxxxxxxxx
<mailto:drkvi-a@xxxxxxxxx>> wrote:
First of all you painted a story saying:
devs had update ready in the night and the user got the update in the
morning! That is misleading !
It was supposed to be an allusion to some kind magic entity like god,
Santa Claus, or the easter bunny. I'm sorry if you're a non-native
speaker and read that literally. I didn't consider that some people
wouldn't get humour, and mistake my jokes for proposals. The story was
supposed to be playful.
BUT assuming that the update state was checked before:
1: Why wait? What is the advantage in deferring the update?
Because we have a problem with how updates are presented. We need to
find a way that makes updates not a chore but a fun task and makes
sure the user ACTUALLY installs them, rather than just ignoring a
notification icon.
2: Why defer a security update to the next boot?
Why defer it for 2 weeks while the icon sits idle. For high priority
updates we may want a mechanism to update the user, this is ok in this
case because it's not a normal update, it's high priority and must be
addressed now. This is similar to the actionable notification debate.
3: What about users who do not shutdown the systems? no updates
for them?
Theyre essentially the same as the autologin people, we say "have
updates been here for <n> days, now we need to show a window because
they havent been to a login screen
4: What if the [non-security]update to a program is deferred to
the next
boot and the program crashes, causing work loss?
What? This isn't a real case. The bug causing the crash existed before
the update was available, the user already know this app is buggy. Or,
the user hasn't ever experience the bug before and may not suffer from
it at all. It's possible the bug might strike in the day before
installing the patch, but it more likely would have already happened
or isn't going to happen. So basically this potentially /prevents/
issues. Currently if you update firefox, a lot of stuff in XUL breaks
due to its lazy loadig
If the propsal for the above is that the system waits [x hrs/days]
before reminding the user of the update.
Do you mean notifiying updates havent been installed or something? Or
Is this a follow up to 4. If it's a follow up to for you can skip the
follow ups with a "im not going to answer because 4 made no sense".
5: what is the use of having updates scheduled for boot?
To help ensure they actually install updates.
6: what is the acceptable time limit to defer an update?[the
update may
be critical to the program the user needs, which has been crashing,
would the user want this update immediately?]
This is irrelevant to the discussion and is an implementation detail.
>
> You DO get on with your work, you just start the update process
first,
> and then move on.
>
What you need to remember is that work may involve net browsing, so
speeds are hampered during the work. The user might mot have
planned on
using the net , but needs to browse for research , so his only
option is
to cancel the on going update?
also if the user is allowed to work and it prompts for reboot, isnt
that a break in work flow? he may choose to do it later , but the main
purpose of the proposal does not achieve its goal .
This is what we do now so this isn't actually a regression. If you
read story (for what, the 3rd time?) you'll see that the user is
NOTIFIED that this update will require a reboot. So the user is
already aware that in a short time theyll be aksed to reboot, they can
chose to wait and go make some tea or proceed with the knowledge that
a reboot will be necessary soon.
--
--Alex Launi
------------------------------------------------------------------------
_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
