Mark Shuttleworth and Jono Bacon

That's a leftover from precise but it would be good to use the upstream "region" panel code and deprecate language-selector next cycle (better to have capplets integrated in system settings that those "launchers" for standalone apps there). We will maybe need some design input on the ui and to finish the coding part started this cycle. +1. The main missing bit here is integrating the ibus module chooser.

As Ubuntu Server depends more and more heavily on automated usage of apt, we're seeing more and more failures of tests, installs, Juju, MaaS that result from apt mirror or proxy issues or general issues in apt's behavior. Here we will address ways we can make Apt more reliable.

Technology update, QML2, architecture changes, Ubuntu needs..

Tasks from daily community roundtable sessions

In this session we will go through the process we are following to choose a great sound theme for Ubuntu.

Server vendors provide additional tooling for analysis of system crashes. This session is to discuss how these vendors can best integrate their tools into apport.

Rationale: Scripts are a key part of the quality we want to achieve. So, we need to organize how we develop and use arsenal, to avoid people being bottlenecks in the process or only one person or another to be responsible for all the structure, which doesn't scale. Define maintenance schema for reports being used to track bugs that the teams are working on (including but not limited to: http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html). Goal: Have a defined process on how to contribute to arsenal (code reviews, mailing list discussions prior to implementation). Communication improved among people involved with arsenal. Not having scripts failing for days or unexpectedly due to changes known to a few.

Python 3.3 will be released by August 2012, theoretically in time for 12.10. Should we make it available in Quantal, and if so, do we keep Python 3.2 or only support Python 3.3. Long term, if history is any guide, Python 3.4 could be released by February 2014, which is probably too late for 14.04 LTS, although we make the alphas/betas available early in that cycle and switch to the final release by 14.04 final. Some arguments for supporting 3.3 in 12.10 include proper support for namespace packages (likely, PEP 420) and built-in virtualenv, among lots of other improvements. Arguments against supporting 3.3 include not being sure that all our packages build against it (especially since it's still in alpha as we speak). Arguments against supporting both 3.2 and 3.3 include the additional disk image space necessary to support both. Arguments for supporting both include a longer and better transition period to a presumably 14.04 LTS world where only Python 3.3 is supported. We also need to consider how this will work with Debian, with their planned freeze in June, after which we can't switch the default Python 3 version.

While Ubuntu runs fine on low spec hardware, the minimal system requirements are still pretty high. Ubuntu will not run on truly embedded hardware, the smallest Ubuntu root filesystem in the form of ubuntu-core still uses more than 100MB diskspace when unpacked. A tool to create even smaller footprint filesystems already exists in the form of initramfs-tools which has hooks and scripts to allow the addition of any binary from the underlying Ubuntu filesystem (or chroot) it gets executed from. Scope of this spec is to research, plan and implement the creation of a truly embedded rootfs builder which creates an absolute minimal filesystem that can also run on hardware with extremely limited diskspace by using parts of the existing infrastructure from initramfs-tools (i.e. copy_exec and friends).

Discuss HA for OpenStack components (RabbitMQ, MySQL, Keystone, Glance) based on the discussion at the OpenStack Design Summit.

Provider-agnostic descriptions of what a given cloud provides, intersects with constraints

Discuss transitioning stable releases to latest OpenJDK for security reasons and for successful Panda buildds. Also discuss strategy once OpenJDK 6 goes End of Life in November 2012.

Discussions on euca2ools, the new features in Eucalyptus 3.0, and the soon to be released Open Source Eucalyptus 3.1.

As part of the work on the LoCo portal this cycle, we'd like to review the current content in terms of the information we present to newcomers to the site, and ensure the core message of the site and all relevant documentation is up to date. In short, we want to ensure that the LoCo portal has prominent additional sections with brief and visually rich information on: - What a LoCo team is - How to join a LoCo team - ...

This blueprint is for scheduling purporses only. Please read the full description at: https://blueprints.launchpad.net/certify-planning/+spec/cert-q-12.10testing

Back when everyone had an xorg.conf and a lot of the X bugs were due to malformed config files, we would collect the files and run them through checkers. Brian Murray ran a bot that'd test xorg.confs in bugs posted to launchpad for instance. Found quite a few issues that way. These days xorg.conf's are rare and hardly anyone hand-edits them so we don't do this anymore (although maybe we should...) But the concept could be applied more generally for config files of all sorts. The most effective thing you can do (IMHO) is create apport hooks for every application that installs a config file, that looks for and attaches that file when a user files a bug via 'ubuntu-bug package'. The hooks are trivial python scripts, basically just: from apport.hookutils import * from os import path def add_info(report): if ui.yesno("Would you like to include your ~/.myconf?"): attach_file_if_exists(report, path.expanduser('~/.myconf'), 'MyConf') [You can omit the yesno prompt if you're absolutely certain there's no chance of sensitive info in the config file, or if you programmatically strip out or hide that info.] Copy your hook to /usr/share/apport/package-hooks locally, and test it out yourself. Once you have it working the way you think it should, post it to the package's bug tracker (ubuntu-bug <package>), and make sure to mark it as a patch. A package maintainer will review and incorporate it into the package. Next, wait, and let a nice database of config files accumulate in launchpad. Then, run a launchpadlib script to download all the configs. Weed out all the dupes. Keep track of the package version. Now make a test that iterates through all the config files, launching the program, and testing if it successfully loads or exits/crashes. If the app has a test suite, bonus, run that too. Finally, go file bug reports (both in launchpad and upstream) for the failures that occur.

Feedback session on what went well and what needs to be tweaked from our experiences in precise. Goal is to keep the experiments that did work, and adjust those parts that were still causing problems.

Discuss AppArmor upstream test suite, and Ubuntu integration testing.

Q&A / BoF on Qt Project governance, community, contributions, state of the project, etc.

Shows we're hitting up.

There are multiple bug reports indicating problems with migration-assistant and it being unsuccessful in migrating items for people. There doesn't seem to be much manual testing done of migration-assistant so it would be helpful if we were to setup automated testing somehow. Problem Bugs Bug 986161 - imported bookmarks from ubuntu not found Bug 986730 - nothing transferred from Windows 7 Bug 980676 - migration-assistant encountering multiple users cause ubiquity to crash Bug 987902 - nothing imported

Chris Kenyon

HP

HP

Marco Ceppi

A previously proposed task within the power-management blueprint that was postponed, implement a NUT module for Zentyal to manage UPS on standalone servers. https://lists.ubuntu.com/archives/ubuntu-server-bugs/2011-July/058794.html

Planning the design of a distributed testing toolkit for Desktop and Laptop hardware. This new toolkit will allow users to access both local and remote resources. Tests can be executed across networks, providing both SUT status and test result reporting. Reasoning: The current tools available for hardware testing are complex and difficult to maintain. This makes feature enhancement slow. There is a need to replace existing tools with a more powerful suite. The largest change to the current set of suites required by the teams involved is remote execution and reporting. The flexibility to execute tests on systems from a centralized location is valuable in both time and resources. In addition, the support for differing workflows is desirable. By making the new suite a library, any number of interfaces can be written to exercise those options. This provides the teams using the library to easily build an interface that exactly meets their needs and process. Work so far: A team of engineers from Canonical has begun work on a python library with the capabilites to execute tests across private networks just as easily as you would on a local system. Prototyping of the basic features is complete and a demo of this prototype will be presented in this session.

For 12.10 we will switch the ARM images from preinstalled to be normal live images. This session is not for discussing technical bits of this change but to get all stakeholders using the preinstalled images together to discuss the possible impact of this move.

A "tablet test-drive" session to encourage Ubuntu-related tablet (and touch screen) development: multiple tablets will be on hand running the following UIs: - Ubuntu / Unity - Ubuntu / Gnome - Kubuntu Active (KDE Plasma Active UI) - WeTab (MeeGo base OS) - Android - Windows 8 We'll set tablets side-by-side and let developers try them: the idea would be to compare and contrast the various tablet UIs to spur (and, hopefully, accelerate) innovation in Ubuntu's tablet OS.

We would like to have a discussion about providing better integration between Xen and Ubuntu.

Discussion of design issues you may have in your software.

A session to discuss the options surround control of an Ubuntu TV from a local network. Example: a remote control app on another device and an EPG guide on another device.

Ubuntu Distributed Development (UDD) is a great way to develop packages for Ubuntu using the Bazaar dVCS. While great progress has been made in previous cycles, there are still some warts around quilt packages and the importer. There may also be other issues we'd like to address for the Q cycle. This session will identify the top needs for Ubuntu developers and attempt to round up resources (both inside and outside Canonical) to tackle the biggest blockers.

BoF/Discussion on things community developers would want in a devops machine that came with Ubuntu.

Discussions on the likely mainline kernel version and appropriate kernel flavors for Q. The current list of arch's and flavor's for Precise are listed below. Distro - Precise 12.04 Arch: Flavour -- Description i386: generic -- kernel for desktop machines with less than 4GB of ram i386: generic-pae -- kernel for desktop machines with more than 4GB of ram i386: virtual -- kernel for virtual machine use (KVM/EC2) amd64: generic -- kernel for desktop/server machines amd64: virtual -- kernel for virtual machine use (KVM/EC2) armel/armhf: omap -- kernel for ARM OMAP-3 hardware armel/armhf: omap4 -- kernel for ARM OMAP-4 hardware Ports - Precise 12.04 Arch: Flavour -- Description powerpc: powerpc-smp -- PowerPC with SMP support powerpc: powerpc64-smp -- PowerPC64 with SMP support

Right now, Wubi is built locally, then uploaded by Evan to http://people.canonical.com/~evand/wubi . This has meant that, on occasion, changes to grub that affect Wubi users, as well as milestone CD builds block on Evan. We should fix this bottleneck by making publishing of new Wubi binaries an automated process. This should, if possible, also sign the Wubi binary.

Identify tutorials and documentation needed by upstream developers to port and integrate their applications with Ubuntu and Unity

Discussing communication strategies, interactions with sister communities and team organization, recruitment and recognition

Discuss where to focus AppArmor development and integration efforts

Discuss current state of the Juju charms for deploying Openstack on Ubuntu and define what is needed to cover new Openstack components being added during Folsom/Quantal.

Care has been taken over the years to ensure that clicking a link to an executable on a website doesn't cause untrusted code to be run, and that all package downloads from the Ubuntu archive and from PPAs can be done securely. But lots of community and third-party documentation directs users to download unsigned .debs from websites and install them, and software center facilitates this. We need to examine the security around third-party packages.

Coding to do in Quantal

The goal of this blueprint is to ensure OpenStack is able to be deployed on ARM server hardware.

Is not an easy task for packages that provide integration between other packages in the archive to be policy compliant. According to the Ubuntu policy a package cannot modify other package's configuration files. Some techniques has been introduced to help on this task, from dotdee [0] to augeas [1], discuss with other developers how to deal with this situation that also affects other configuration management software like puppet, juju, etc. [0] http://blog.dustinkirkland.com/2011_04_01_archive.html [1] http://augeas.net/

Discussion of changes that would help: - release team with managing and publishing images, understanding the quality/shipability - qa teams (ubuntu and flavors) for understanding quality of images and issues for developers - testers ease of using system, logging results, automated logging, knowing bugs

A primer on what juju is for the common person.

Promote and run a successful series of online app developer events, including at least: - The Ubuntu App Developer Week - The Ubuntu App Developer Contest