This page is here to collect together proceedings from sessions as part of sessions that don't fit one of the pre-defined tracks at the Natty UDS in Orlando, Florida.

Please add proceedings by doing the following:

• Add a new section with the name of the session.
• Add the outcomes of the session as a collection of bullet points. The goal of the proceedings is to really focus on decided outcomes, so please try to keep them crisp.

Thanks!

Proceedings

Paper Cuts for Natty

• Vish has been doing a lot last time, but he shouldn't have to do all work. This cycle more people should help him with triaging paper cuts;

• There will come an open Launchpad team, for everyone who is interested in fixing paper cuts. This team gets assigned to all paper cuts that are accepted, so the team's mailing list gets a mail and the team members know there is a new paper cut to fix;
• Until other package description projects get going we should continue to accept descriptions paper cuts, but they could be moved to a separate milestone;

• There will be a separate 'Paper Cuts'-like project for Unity, so the One Hundred Paper Cuts Project should be about applications and upstreams;

• Paper cuts in featured applications and in applications of upstreams willing to cooperate will be accepted during the Natty cycle as well;
• We will cooperate more directly with upstreams and Debian with regard to the package descriptions, to make sure our improvements benefit other projects as well, and we get feedback from the people who know the applications like no other;

• Vish will select the milestones for the Natty cycle;

• JonoBacon, JorgeCastro, SenseHofstede and Vish should generate (more) buzz at the usual channels about fixed paper cuts, including quotes from happy upstreams in the posts;

• We will investigate the possibility of using Launchpad Translations and a custom version of US English to provide a temporary easy way to modify package descriptions in Ubuntu;

• JorgeCastro will communicate our package description improvement effort to Debian, to make sure the Debian Developers understand what is going on and are prepared for our forwarded bug reports.

Testing Ubuntu on different architectures

• Only the testcases with subscribers in the ISO trackers will be built.
• Distributions will choose what architectures and "special testcases" they commit to.
• We will have regular names for architectures and distro names.
• The release manifest will include only the images that were tested properly.
• All this process should be automatic
• This change of policy will be announce to ubuntu-devel-announce

Cross-compilation Environment

• We will pursue and extend the efforts started under the ALIP umbrella to cover a larger set of packages
• Automation will be setup to test cross-compilation of the new package set in both in "from scratch" and "source by source" modes
• Multiarch control fields will be used to classify packages in host versus build packages

Kexec

• Kexec needs lot of fixes and testing on ARM, subarch by subarch
• Will extend kexec to cover device tree
• Some demo / test features will be implemented with kexec (kexec-reboot, boot menu etc.)

Kernel configuration management

• Will create a dataset of config requirements as to allow tailoring the config for a distro, or for a product
• Only machine specific configs could possibly be stored upstream
• Needs policies for Ubuntu and for Linaro to define common configs such as networking, security etc.

ARM gdbserver support

• gdbserver will be included in developer images
• New package for an armel cross-gdb
• Developer experience will include a new tool to grab debug symbols from ddebs
• Will develop new test frameworks and safety checks

Reinvigorating the artwork team

• Design a questionaire - Ivanka
• Set up fortnightly meetings - Iain/ Ivanka/ Docmo
• Move the previous questionaire to a central place- docmo
• Email the loco team leaders the survey- have them direct
• Publicize the survey- on blogs, lists

Defining Gestures in Ubuntu via Configuration

• Agreed that physically literal gestures don't need configuration options

Using QEMU for demonstrations

• many of Linaro's other outputs (kernel power management, performance, graphics improvements) are not demoable via qemu
• we should get the Beagle XM model working with Linaro images (as a compromise between memory size/capability and being a platform Linaro supports in h/w)
• investigate/use the paravirtualised OpenGL work done by Nokia for maemo/meego
• good audio support is tricky -- low priority

Using QEMU for development

• for development users we need not be modelling real hardware : we should define a "virtual platform" which is simpler and less prone to fragility in the face of kernel changes, and has more memory, fast virtual devices, and so on
• we are effectively "filling the gap" between now and when native ARM dev/build hardware is more prevalent/cheap
• need to test/validate qemu so it is trustable as a dev platform
• need to consolidate qemu trees to avoid the "which qemu should we use?" problem

Session Name

• Outcome
• Outcome
• Outcome