From Fedora Project Wiki
< Desktop | Whiteboards
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]]. | ||
[[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), | * 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.
.
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.