From Fedora Project Wiki
No edit summary
(Categorize page)
 
(3 intermediate revisions by one other user not shown)
Line 3: Line 3:
See requirements and discussion at [[Desktop/Whiteboards/UpdateExperience]].
See requirements and discussion at [[Desktop/Whiteboards/UpdateExperience]].


Also see screenshot of [[FUDCon_Desktop_Update_UX_Whiteboard.jpg]].
[[File:FUDCon_Desktop_Update_UX_Whiteboard.jpg|thumb|whiteboard screenshot]].


== Fedora Process ==
== Fedora Process ==


* Enhancement (anything non-security) updates are scheduled for once a month
* Enhancement (anything non-security) updates are scheduled for once a month (at least for core, extras might be more flexible).


== Running app (firefox) update (security and enhancement) ==
== Client UI ==
 
=== Running app (firefox) update (security and enhancement) ===


* Separate download process from install
* Separate download process from install
* Add functionality to yum to detect what packages are currently running (doable at high confidence for c/c++, e.g. scripted plugins are a hard case, ignore for now)
* Add functionality to yum to detect what packages are currently running (doable at high confidence for c/c++, e.g. scripted plugins are a hard case, ignore for now)
* PackageKit daemon wraps said functionality
* PackageKit daemon wraps said functionality
* For running apps (apps, i.e. open X windows), show a dialog indicating they need to be closed (also, window manager adds (Update Available) or something to title)
* For running apps (apps, i.e. open X windows), pk-update-icon shows a dialog indicating they need to be closed (also, window manager adds (Update Available) or something to title)
* On clicking "Apply", pk-update-icon sends a close request to all windows corresponding to that process it finds (in sequence?)  (TODO: standard application dbus interface?)
* On clicking "Apply", pk-update-icon sends a close request to all windows corresponding to that process it finds (in sequence?)  (TODO: standard application dbus interface?)
* When application is closed, packagekit starts updating that app (+ dependencies)
* When application is closed, packagekit starts updating that app (+ dependencies)
Line 21: Line 23:
* Other notes: Should block application relaunch during updates too; show the user the updater dialog
* Other notes: Should block application relaunch during updates too; show the user the updater dialog


== Non-running application security updates ==
=== Non-running application security updates ===


* Similar dialog as above, but without close button?
* Similar dialog as above, but without close button?


== System updates (security and enhancement) ==
=== System updates (security and enhancement) ===


* All desktops are logged out, system switches to gdm (or plymouth?)
* All desktops are logged out, system switches to gdm (or plymouth?)
Line 31: Line 33:
* perform a "dependency reboot"; e.g. if kernel/init/dbus, do a full reboot.  Otherwise, for system daemons do "service foo restart".
* perform a "dependency reboot"; e.g. if kernel/init/dbus, do a full reboot.  Otherwise, for system daemons do "service foo restart".


== System security updates ==
=== System security updates ===


* Similar to running app - if it's on the system it's implicitly running, basically.  It's either a crucial library like glibc, a key system daemon like NetworkManager, or a general program like curl that we can't know reliably when it might run.
* Similar to running app - if it's on the system it's implicitly running, basically.  It's either a crucial library like glibc, a key system daemon like NetworkManager, or a general program like curl that we can't know reliably when it might run.


== System non-security updates ==
=== System non-security updates ===


* By default, apply automatically when safe (shutdown/reboot, configurable timeout (one week?)).  Note availablity of updates at context switch time (screensaver, gdm).  If configured to prompt, do so of course.
* By default, apply automatically when safe (shutdown/reboot, configurable timeout (one week?)).  Note availablity of updates at context switch time (screensaver, gdm).  If configured to prompt, do so of course.
[[Category:Desktop]]

Latest revision as of 19:07, 15 August 2015

Implementation tasklist for better update experience

See requirements and discussion at Desktop/Whiteboards/UpdateExperience.

whiteboard screenshot

.

Fedora Process

  • Enhancement (anything non-security) updates are scheduled for once a month (at least for core, extras might be more flexible).

Client UI

Running app (firefox) update (security and enhancement)

  • Separate download process from install
  • Add functionality to yum to detect what packages are currently running (doable at high confidence for c/c++, e.g. scripted plugins are a hard case, ignore for now)
  • PackageKit daemon wraps said functionality
  • For running apps (apps, i.e. open X windows), pk-update-icon shows a dialog indicating they need to be closed (also, window manager adds (Update Available) or something to title)
  • On clicking "Apply", pk-update-icon sends a close request to all windows corresponding to that process it finds (in sequence?) (TODO: standard application dbus interface?)
  • When application is closed, packagekit starts updating that app (+ dependencies)
  • Application is restarted (pick first .desktop file in package? eww. require backporting GNOME Shell application tracker as dbus service?)
  • Other notes: Should block application relaunch during updates too; show the user the updater dialog

Non-running application security updates

  • Similar dialog as above, but without close button?

System updates (security and enhancement)

  • All desktops are logged out, system switches to gdm (or plymouth?)
  • gdm shows updater screen
  • perform a "dependency reboot"; e.g. if kernel/init/dbus, do a full reboot. Otherwise, for system daemons do "service foo restart".

System security updates

  • Similar to running app - if it's on the system it's implicitly running, basically. It's either a crucial library like glibc, a key system daemon like NetworkManager, or a general program like curl that we can't know reliably when it might run.

System non-security updates

  • By default, apply automatically when safe (shutdown/reboot, configurable timeout (one week?)). Note availablity of updates at context switch time (screensaver, gdm). If configured to prompt, do so of course.