UDS Intrepid Platform Report

[:UDS-Intrepid/Report:back to the reports index page]

Plans for 8.10

Place in this section bullet points of specific intended outcomes for the 8.10 development cycle.

• Outcome
• Outcome

Sessions

Session

19 May Round Table

Boot performance

We need faster boots for various reasons: mobile, laptop, etc. It's also just generally nice.

Overview

boot process spends a lot of time in initramfs:

• initramfs stuff written in shell -> slowish

• probing is fast, except for some systems like mobile stuff (ogra)
• cpu is finite, but fast
• ram is fast, we don't care about it much
• disk is really, really slow
• readahead is a static list that should be regenerated often to be really useful

• flash devices should not use readahead-->Detect type of disk.

• readahead is up to date after a new fresh install
• prefetch is a potential new way of doing what readahead does

Readahead problems: 1) operates on file-by-file basis 2) generating the lists is very difficult

Prefetch is kernel-level

• works on disk blocks => more efficient

• essentially self-updating
• however, needs some work to be actually usable (at least for this)
• documentation!

during boot, we're cpu bound during modprobe (via udev?). mobile is almost entirely cpu bound

• Keybuk: udev-settle is completely pointless, udev could just be started early
• plan to do that, is after intrepid, probably intrepid+1

• Artir:Use bootchart to check boot time changes caused by improvements.

rc2 is highly subjective to people's configurations (but we could benchmark default install)

mobile with fixed hardware may gain a lot of boot speed by compiling drivers into the kernel

X/gdm should start earlier, but this requires dbus+hal to be started earlier

Goal 25 secs?(On Core2Duo, 1 Gb Ram p.e.). Less on QuadCore systems?

Solutions

1. Use multithreading. Take advantage of multi-core systems.-->Detect processor.

2. Auto regenerative readahead and grub autoprofiler.

3. Preload&Prefetch&Grub auto-profiler by default

4. Restructure boot order

Plan for intrepid:

• prefetch
• Better multithreading
• dbus, hal moving to upstart
• elimiante udev settle
• stop X from stating like crazy at startup.(Kernal based modesetting)

20 May Round Table

Ubuntu Distributed Development - Importer

• Aim to have all of Ubuntu, and possibly Debian imported during the
  • Intrepid cycle.
• Use the upcoming features in bzr and launchpad to make it very quick
  • to make small changes.

OpenOffice.org upload schedule

• preferred upload timeframe 1 week before milestone release.
• Estimated upload of 3.0rc - Alpha 4
• Estimated upload of 3.0 - Alpha 6

• http://wiki.services.openoffice.org/wiki/OOoRelease30

OpenOffice.org language packs

21 May Round Table

• Notes
• Notes

Upgrade hints (really: remove cruft after upgrades)

Post-hoc hints for cleaning up system from non-update-manager upgrades; incorporate:

• apt-get autoremove
• replacement of now-unsupported packages
• cleaning up old kernels (has been pending for ages, should happen independent of the rest)
• deborphan?
  • finds rather more packages for apt-get install users, so still useful for several people
• deprecated dotfiles?
• purging removed packages with configuration files
  • only unmodified conffiles (or ucf-managed files)?
    • code for this in unattended-upgrades already (mvo)
• .dpkg-old/new files?
• the cruft program exists (used to?)
• random files belonging to packages that aren't removed by remove
  • (piuparts finds these)

Michael reluctant to add to update-manager UI itself; update-manager should only install packages, not remove them, otherwise people will be more reluctant to run it

Most applications of a cleanup tool are package-related

Need to add upgrade hints for certain packages moved from main to universe. Also installer changes (e.g. relatime)

Code in update-manager mostly fairly separate

Some is more difficult to perform after installation due to lack of context (e.g. no knowledge of previous state)

• libapt could record previous state in its extended_states file

Cleanup items need to have a "no, and don't ask me again" option, which is difficult to incorporate into current update-manager design

Loose consensus to add new System -> Administration entry for this tool due to this; mvo and liw to talk with mpt

Ubuntu policy manual and standards

Documents describing policy and standards are difficult to track in the wiki:

• no changelog
• completely lost if you return after a break
• no upgrading-checklist.txt

https://wiki.ubuntu.com/UbuntuPackagingChanges

debian-policy is mostly appropriate except for section 3

it's important to preserve section numbers

developers-reference for workflow

Refer to UbuntuArchitecture

Policy changes:

• Maintainer
• python-minimal
• Components and sections
• Seeds
• Upstart
• /var/run as a tmpfs (also should go to Debian)
• udev changes compared to debian
• casper
• Package versioning

• See UbuntuPackagingChanges

• experimental -> PPA

• Standards-Version: should refer to the ubuntu policy?
  • Avoid frivolous Standards-Version: diffs
• call it ubuntu-policy, keep debian-policy in archive identical to Debian's

Developer's reference:

• Merging
• Resources such as ubuntuwire.com and REVU
• Language packs

• Branding (cf. DistributionDefaultsAndBranding

• Source-only uploads (incl. lack of binNMUs)
• References to archive structure, admin, etc.
• Release scheduling: perhaps external reference
• Require upgradeability between LTS releases (policy or reference?)
  • Some kind of argument about partial upgrades

Announcement of changes:

• including merged changes from Debian
• diffs sent to ubuntu-devel
• changelog (or similar) sent to ubuntu-devel-announce

Revitalise ubuntu-devel!

Lightweight process on ubuntu-devel for making changes

• Post proposed change (description or diff)

• If no objections, anyone else may apply diff (to avoid one-man changes)

• If objections, discuss

Spec: foo