Desktop/Whiteboards/UpdateExperience

Our current package-centric view of software installation and updates is less than ideal.

We really want to let users easily find, install and deinstall applications, not packages.

Most non-nerdy users are not interested in learning about updates to a million tiny packages they have never heard of. It would be much better to represent everthing that is not an application update as a catch-all 'system update'.

To get this, we need to differentiate between applications and system components, and treat updates for these differently. Installing application updates should be at the users discretion, but updates system components may happen automatically (at least by default) and in way that minimizes interruptions to the user (install them when the system is idle, at shutdown, etc)

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
• 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

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 must fix critical bugs or security vulnerabilities only
• 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