Desktop/Whiteboards/UpdateExperience

Problem

We currently provide our users with a very poor experience when updating their operating system.

Our current package-centric view of OS software updates is less than ideal. Most people are not interested in learning about updates to hundreds of tiny packages they have never heard of.

These myriad individual updates aren't even well coordinated. They arrive at the user's computer and pester her to update them in a random and seemingly continuous stream. This does not show respect for the user's time.

The many combinations of packages that are possible due to this lack of coordination means that we don't actually test any of them. There is no set that is canonical or even most likely.

So, basically, what we have today is:

• Arcane
• Uncoordinated and disruptive
• Often broken, fragile, and largely untested

A very poor user experience.

Requirements

All releases

• System components must be tested as a single unit before release
• System components must be presented to the user as a single install unit
• System updates must not break any application that we define as critical (Firefox, etc)
• Users should be able to detect whether updates are available from within the app they are using
• Application updates should appear to the user as a single object (ie. not a set of loosely related packages)
• Applications must not install updates on their own but should work in concert with a central update installer.
  • To limit the number of potential reboots after installs
  • To offer the option of opting out of certain types of updates
  • To not have to prompt the user repeatedly in different ways
  • So applications don't expect that they can do whatever they wish
  • So we can better test the combinations of software
  • Allow users to discover or be reminded of pending updates
  • To allow users to batch update disruptions
• Release engineering may be free to withdraw or block a package if it breaks the integration tests
• System must have a way to defer or queue updates to currently running software
• System must be able to download updates in the background using idle time and bandwidth
• System must be capable of installing update non-interactively (no prompting)
• System must be capable of installing the updates that require restarting at shutdown time
  • This is a natural break in the user's flow
  • The process can be left unattended and it will power off the machine when complete

Stable releases

• Batched updates must occur and appear to the user no more often than once per week
• Tuesday suggested as the update day
• System updates should only:
  • fix critical bugs or security vulnerabilities
  • provide hardware enablement
• System updates may only be deferred for a short time after which they will be installed automatically
• System updates should be able to run autonomously when the user requests a shutdown (but not necessarily on reboot since a reboot means that the user wants to resume operation and is not done with the computer)
• Application updates may be deferred or permanently ignored at the user's discretion
  • One reason for this is that for the user the system is working fine and changes may be known to break workflows or habits or devices.
• Application updates may add new features even in a stable release at the upstream brand's discretion as long as someone can be held responsible for fixing problems
• Should perform more testing on or elimination of "zero-day" updates after a release
  • Thoroughly testing of a release is irrelevant if the system is never in that state and random updates are installed almost immediately.

Rawhide

• Nightly composes should be tested to boot, start a graphical user session, and load a web page before being pushed out
• There should be a weekly or bi-weekly snapshot stream/repo for early adopters that do not want the nightly changes
• Weekly snapshots should receive more testing than the nightly and a broader category of functionality should be confirmed to work
• It should always be dog-foodable and should never be known to be severely broken
• We should take our Alpha, Beta, etc releases more seriously

Testing

NOTE: THIS PART IS SKETCHY

All snapshots (including nightly Rawhide) should ensure they don't break the following: System boots and can get to a web page to get help for minor issues if needed

In detail this means the following must work:

• Grub

• Kernel
  • process input
  • detect monitor
  • display output
  • support root filesystem
  • support home filesystem

• Dracut
  • mount root filesystem

• Plymouth
  • only for encrypted disks?

• Xorg
  • process input
  • detect monitor
  • display output

• GDM
  • autologin user

• gnome-session
  • since nothing starts without it
  • handles logout

• gnome-settings-daemon
  • xrandr

• gnome-panel
  • displays network applet
  • allows starting web browser

• NetworkManager
  • connect to wireless

• Firefox
  • load website

Related Work

• https://fedoraproject.org/wiki/Automated_QA_Testing_Project
• http://fedoraproject.org/wiki/Critical_Path_Packages_Proposal
• http://fedoraproject.org/wiki/Fedora_Activity_Day_Fedora_Development_Cycle_2009#Resulting_Output
• https://fedorahosted.org/pipermail/autoqa-results/2009-August/thread.html