Ubuntu Wiki

• Launchpad Entry: foundations-lucid-lts-upgradesoo

• Created: MichaelVogt

• Contributors: lots

• Packages affected: update-manager

Summary

Its important to provide a smooth upgrade experience. With the upcoming LTS release we have to support two upgrade pathes (8.04 -> 10.04 and 9.10 -> 10.04). Its important to test those as good as possible.

Release Note

TBD

Rationale

Upgrades are important to our users. We need to provide a clean and smooth experience.

User stories

Julie is staying on the LTS because stability is important to her. When the new LTS is announced she decides to upgrade when its offered via update-manager.

Design

Testing and learning from the experience of the previous upgrades is importing for this upgrade. We are going to focus strongly on testing this cycle.

High level problems

• nvidia/fglrx driver often fails: see https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers

• grub problems (old kernel running): we solve this via grub2 upgrade
• upgrade semi-automatically changes panel applets/indicators (user configuration): DX team/desktop team
• python problems in hardy (old python-central): lots of testing
• accumulated kernel versions: more agressive removal
• lpia will be discontinued: mail from the mobile team suggests they do not want to provide a upgrade path

We can enable the upgrades for 9.10 to 10.04 independently of the upgrade from 8.04 to 10.04. So we can decide to enable the LTS upgrades later to ensure the quality of the upgrade is high. We will decide at beta2 if that should be done for hardy users or not.

Automatic upgrade (via the auto-upgrade-tester package) is important, we should also look into enabling a "universe-all" test again this time (this has proven to be tricky in the past, the amount of packages makes dpkg really slow). Even if we can not install them all together we should aim towards a setup where they will get at least tested in partions of ~5000 at a time.

Encourage testing on real hardware with instructions like: http://www.fabianrodriguez.com/blog/2009/09/23/almost-risk-free-karmic-testing/

Marjo will talk to Marc and Ronald about whether upgrades can be tested on real hardware in the certification lab. Also to find whether it would be possible to run a desktop upgrade test, driving the UI to ensure that desktop elements don't crash.

A special focus should be on the python upgrade robustness, we need to ensure that the python tools get it right. A special test mode in the auto-ugprade-tester should be added that can test if the available python modules can still be imported after a upgrade.

Thinks to watch out for:

• kernel name changes (no -server, -pae, ...)
• improve the failsafe session and provide a way to backup/clean
  • some gconf keys

As a target of opportunity we should look into adding the ubuntu-slide-show (or a special version of that) into the release upgrader to make people aware of the new feature of the release.

Implementation

See work items

UI Changes

No UI changes other than the (target of opportunity) port of the slideshow.

Test/Demo Plan

TBD

CategorySpec