UDS Jaunty

This page is used as an overview to the Actions Items that came out of the UDS sessions. This of this as the "punch list" of things to get done for Jaunty and who is doing them.

Jaunty Kernel Schedule

UDS Admin

  • Update the Kernel Team Road Map
    • => pgraner - 17 Dec (Complete)

  • Publish the UDS Actions list to team
    • => pgraner - 17 Dec (Complete)

  • Publish timeline to kernel team google calendar
    • => pgraner - 17 Dec (Complete)

  • Add all kernel team members to kernel team google cal for editing
    • => pgraner - 17 Dec (Complete)

Kernel Process


Session covered the release process from start to finish and diagrammed on the white board. This was done so that critical milestones could be identified at the appropriate points in the release cycle.

Action Items

  • Create Diagram and create/update kernel team wiki page to reflect the session
    • => pgraner - 31 Jan

Kernel Tree Management


This discussion centered on the Kernel Team's git tree and how its managed.

Action Items

  • We need to communicate to the community better why we rebase rather than follow a head. Need better information in the wiki - mentioned in kernel devel pages??
    • => apw - 1 Feb

  • Discuss and decide whether we need to deliver historical changelogs. Kernel team meeting with community.
    • => pgraner to add to IRC agenda after holidays.

  • Is there more information we should be putting in the commit?
  • Provenance is important
  • At what point should we require a bug per commit?
  • It's an extension of out current process.
  • We will do this when we're out of the rc process and have declares our tree stable
    • => apw will investigate doing this using commit templates and commit hooks, needs to be complete by Beta1 Freeze.

  • Take the email that Tim sent about the last rebase, put it in the wiki, and make it a template as part of the rebase process.
    • => apw to find email in the archive and edit wiki

  • Publish a schedule of kernel uploads on Google Cal
    • => smb for intrepid and previous - ASAP

    • => rtg for Jaunty - ASAP

  • work with AUFS maintainer in getting upstream
    • => amitk - on going

  • Review all items in /ubuntu and get them in upstream stable if not already there or drop
    • => BenC - Alpha4



Suspend and Resume (specifically resume) continues to be problematic. Due to hardware complexity and availability the problem is complicated by an order of magnitude. For the Jaunty cycle we decided to narrow the scope of hardware specifically, ship testing scripts that can be run by a limited set of users to see what works and whats broken. It was decided that the initial hardware set will be all the canonical engineers. Each engineer will run the live image on their notebook, run the test script and report. This will be targeted for the Canonical engineers however others may contribute as they see fit. Once we hit the Beta cycle we will put out a call for testing publicly (mailing lists & IRC) and widen the net.

Action Items

  • Initial version of test script into the kernel package
    • => apw - Alpha3

  • Set up a public wiki describing the testing, how to file bugs etc...
    • => apw, ogasawara - complete by Alpha3

  • Issue a Call For Testing Internally (Canonical Engineers)
    • => ogasawara - Prior to Alpha3 and every release from then on

  • Issue a Call For Testing Public
    • => ogasawara - Prior to Beta1 & RC

  • Investigate removal of usplash and cleaning up kernel messages i.e. clean screen
    • => apw

  • Removal of the ACPI method of suspending - pm-utils will be the only method
    • => BenC - Prior to Alpha3

  • appport lashup for bugs on resume failure (maybe success?)
    • => sconklin - ASAP

  • can we figure out how apple/vista does the suspend and suspend to see if we can gleen any ideas
    • => pgraner

  • review the 'how to diagnose and fix' resume problems
  • swap on file, can we do anything here to help in the process currently does not work.
    • => BenC

Boot Performance


  • This session was strictly about how to boot the kernel faster, userspace & desktop was not discussed. The big take away is that common modules will be built into the kernel for boot essential devices. Module loading is the most expensive thing we do. This will shrink down the initrd size and have less module loads. There are other quick wins we can get as well (outlined below). Also we will be getting a new module-init-tools package that uses a binary index rather than a flat text database which upstream claims is much faster.

Action Items

  • Reduce grup timeout from 3 to 1 seconds
    • => BenC - Alpha4

  • Turn on compiled in modules and document
    • => rtg - Alpha4

  • Data mine the hardware database & SMOLT for data about specific hardware and modules in use

    • => pgraner

  • Create a wiki page on how to use the new kernel boot profiling option
    • => rtg

  • get rid of l-r-m and dkms it
    • => rtg - Alpha4

KernelTeam/UDS/Dec2008 (last edited 2008-12-17 19:21:57 by nc-65-40-95-196)