The ubuntu community continues to target new platforms like the phone, tablet, and tv. Each contains unique quality needs. Let's plan and evaulate testing needs for each of the platforms and how we can shape our testing efforts in support of these

The proposal for rolling releases is predicated on the belief that we will continue to maintain daily quality in the Ubuntu development release and that updates will continue to flow smoothly into the development pocket. This means we need to make sure we continue to provide adequate support for the +1 maintenance team.

The Ubuntu Touch preview images released in February are based on quantal. Identify the work required to forward-port these to raring and integrate them into the Ubuntu archive.
This discussion is only for the components canonical is not upstream for and can mostly be found at: https://launchpad.net/phablet-extras. A full session is dedicated to the components we are upstream for (https://blueprints.launchpad.net/ubuntu/+spec/client-1303-delivering-touch-apps-to-raring)

Currently the Ubuntu Touch based image delivers full hardware accelerated video decode and rendering support by reusing the Android Media Player via libhybris.
While this solution works, it creates issues when moving forward with Desktop convergence, as generally Gstreamer is supported instead.
Another goal we need to keep in mind is reducing the amount of running Android services, and trying to just isolate the Android Hardware Abstraction Layer, making our common and generic stack to make use of it otherwise (see https://blueprints.launchpad.net/ubuntu/+spec/client-1303-sound-support-pulse-audioflinger for a similar discussion, but related with audio support).
As the Gstreamer SDK now delivers Android support, one possible solution would be to isolate the media bits responsible for video decode/rendering and use Gstreamer on top it. That would allow Gstreamer to be used in our convergence history.
Goals with this session:
* Describe the current solution and cover what is not desired when looking from the convergence pov
* Investigate the work done for the Gstreamer Android SDK, and evaluate if it'd indeed be a feasible solution
* Understand how DRM fits in the picture (might be needed for hardware vendors)
* Propose a future convergence plan

It has been proposed that Ubuntu adopt a rolling release model + LTS instead of a 6-monthly release cadence. This session is to continue the discussion started on @ubuntu-devel:
https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html
Discuss the pros, cons, and consequences of such a change for the Ubuntu community and the project, and perhaps flesh out some of the details of how this would be implemented if we went ahead.

Ubuntu touch development is full steam ahead. Many of it's core applications are currently being written, and it's test images are in the hands of developers. This is an excellent opportunity to provide best practices, guidance, and testing expertise to this new platform as it's being formed. How can we help to ensure the images and applications are of good quality?

CheckBox is a tool used by the Hardware Certification (HW Cert) team to test and certify laptops, desktops and servers with Ubuntu. CheckBox is also used for some aspects of testing Unity and will most likely be used for the revitalized Ubuntu Friendly initiative.
The last UDS saw discussion on the issues related to the technology behind CheckBox:
https://blueprints.launchpad.net/certify-planning/+spec/cert-r-checkbox-simplification
At that time there was no concrete proposal on how to address those issues and improve quality, speed or maintainability. During the last few months the HW Cert team has made large inroads into replacing the core of checkbox with new, better architecture known as PlainBox.
We would like to use UDS to share our progress with other teams in Canonical as well as community members who may be interested in using CheckBox or may be more interested in PlainBox itself.

This blueprint is about defining how to deliver the excellent work done by the PS in all the components we are upstream for, adapting them to raring, following your quality requirements and processes like daily release.

During the Ubuntu bootstrap for the Touch images, we needed a way to easily use the audio subsystem by interfacing with AudioFlinger (to provide easy access to the proper device audio configuration). As a solution we decided to extend the support for Alsa/PulseAudio done for the Motorola webtop project, which creates an Alsa PCM that connects with AudioFlinger via Binder (by making Pulse just another audio track).
Some issues with this solution:
* Audio latency (we end up having 2 sound servers running at the same time)
* Lack of control of the audio routes using the available APIs (mic, speaker, earpiece, headset)
* Limited amount of mixer control
As PulseAudio is already the main sound server used by the desktop, it'd be desired if it could also be the main sound server for Touch. Then to still be able to reuse the sound related components from Android, we could reuse the AudioTrack API support at libpulse done by Arun Raghavan (for Galaxy Nexus).
Goals with this session:
* Discuss and understand the limitations with both solutions
* Evaluate what would be the effort needed to port PulseAudio to a new Android device
* If going with Pulse is a desired solution, come to a plan to reuse our current solution as a transition (until more devices are available for Pulse to control natively).
Links:
* https://launchpad.net/android-audiosystem
* http://arunraghavan.net/2012/04/pulseaudio-on-android-part-2/

Review work items pending in the raring cycle, and discuss appropriate path forward.
Now that OpenStack has matured even more, High Availability is one of the components on which more concentration is required. HA support for certain components of the infrastructure have been provided in the form of Resource Agents, however, these do not address some of the uses cases.

Currently Android is the first and main host OS for the Touch project, with Ubuntu living inside a container (the communication between both happens via hybris, binder or socket).
The goal of this session is to discuss if this model should be continued, and/or identify possible alternatives. The most desired solution, from the maintainability point of view, is to have Ubuntu as main host and with the Android isolated based on what is needed and used by the system (Android is needed so we can reuse the Hardware Abstraction Layers).

Given the current discussion of transitioning to a rolling release between LTS releases, how would we continue to deliver hardware enablement stacks for the 12.04.3 and 12.04.4 LTS point releases. We anticipate the point releases with enablement stack offerings will continue to play an important role in allowing Ubuntu to run on the latest hardware to hit the market. The purpose of this session is to discuss how we will continue to deliver hardware enablement stacks in subsequent point releases and how the HWE stack policies and procedures established today will be changed in the event that we move to a rolling release between LTS's.

Review work items pending in the raring cycle for LXC and QEMU.
qemu-kvm is the preferred hardware emulation platform in Ubuntu. The goal of
this work is to follow and help test upstream development, collaborate on
bug fixing with upstream, and ensure that kvm is stable and fullfills our
needs.
lxc is the chosen lightweight (linux-guest-only) virtualization platform on Ubuntu.

Rationale:
Communicating the current health of a charm in a given provider is essential to Juju users deploying Charmed services into a cloud. Developers should also be made aware if their particular charm is failing due to a recent commit, change(s) by cloud vendor, or promotion to new Ubuntu release. There is a need to provide a process and mechanism to validate the quality of a charm in both unit testing, and workload testing. This Blueprint is to plan work relating to ad-hoc charm testing, automated charm testing, and continuous integration testing.
Goal:
-Test a charm on promotion to charm store.
-Gate Charm commits on charm testing success.
-Provide a mechanism for users to test their charms.
Two modes of testing:
-Unit (does the charm start, and report ready)
-Workload (test the charms relations, and pushing data)