HardyToLucidUpgrades

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.

As a target of opportunity, we should export https://launchpad.net/ubuntu/+archivemirrors-rss as a static file somewhere on archive.u.c so that u-m can fetch a update of it during the 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
  • Disk space in /boot needs additional space to store a new initrd (first uncompressed and then compressed)
  • The linux-restricted-modules-common package needs to be forced to be uninstalled (empty package) as it causes problems with the binary graphics drivers.

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

BOF discussion notes

High Level Problems

When to offer the upgrade?

  • dapper -> hardy: at 8.04.1

Possibility to only recommend to some users at first, maybe by putting something in -proposed.

Point in the cycle to decide whether to delay? By beta 2.

Karmic users will be offered the upgrade on release day, a delay would only be for hardy users.

We would not want this to be an excuse to not aggresively fix the bugs

Upgrade testing, possibly in the cloud, with lots of packages installed should be done, but doesn't catch a lot of the issues that users actually have.

(support team@Montreal): Testing bare metal can be done by using an external storage full install, first backup then use this script (or similar method): http://www.fabianrodriguez.com/blog/2009/09/23/almost-risk-free-karmic-testing/

If lpia is going away then upgrades will be "interesting" for them.

Marjo to 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.

Robustness:

  • - python issues (PYTHONPATH=/usr/share/pyshared ?)

Testing:

  • - instead of headless, run while full gnome desktop is running, autologin - test on real HW in certification lab - test upgrade with mago

    - dapper -> hardy -> lucid ; jaunty->karmic->lucid - restest dapper -> hardy to find any outstanding issues for SRU

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
    - Disk space in /boot needs additional space to store a new initrd (first uncompressed and then compressed) - The linux-restricted-modules-common package needs to be forced to be uninstalled (empty package) as it causes
    • problems with the binary graphics drivers.


CategorySpec

FoundationsTeam/Specs/HardyToLucidUpgrades (last edited 2009-11-30 22:59:30 by 99-156-85-10)