Sessions at Ubuntu Developer Summit (UDS-Q) on Monday 7th May

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.

Tasks from daily community roundtable sessions

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.

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).

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/repo...).

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.

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

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.

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.

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.

Discuss AppArmor upstream test suite, and Ubuntu integration testing.

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.

This blueprint is for scheduling purporses only. Please read the full description at:

https://blueprints.launchpad.net...

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

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.

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

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

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

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.

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