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.

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.

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

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

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.

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/

Testing strategies for user-space testing of the network stack (network manager, etc).

This session is to discuss providing object storage in OpenStack deployments with ceph. The blueprint is used for tracking work needed to be done in order to accomplish this. This includes charms, relevant packaging, and testing needed.

External testing, that is, the testing performed outside of Canonical certification labs, is a significant part of all the testing activities around Ubuntu that is growing on every cycle. It is becoming more common that people outside the certification team want to run our certification tools and tests, to either submit results to Friendly, test their systems, or check if a system would pass certification. As part of the continuous improvement practices currently in place, the certification team will focus on enhancing the user experience for external testers for both desktop and server, so that they can run test cases with the maximum coverage (both for hardware and software) and report problems effectively. The areas that have been identified to work on during the next cycle are the following ones: == Test case usability improvement == Some test cases executed internally in the laboratory assume the presence of devices and configurations needed to run them smoothly. Unfortunately, when these test cases are executed in a different environment, they fail and cannot be used unless all the prerequisites are properly fulfilled. * We need to take into account that for the external whitelist is going to be run outside the lab, so we cannot make assumptions on configuration * Automate as much as possible to get rid of any assumption and also run the test cases on any system that matches a minimal set of requirements. * Provide guidelines either in the documentation or the test case description to configure the environment properly when full automation isn't attainable. * Improve general usability of the testcases, to allow people less familiar with the tools, to run the test suite without having to ask questions. == Documentation == Documentation is intended to solve any doubt that could prevent a testing session from finishing properly with the submission of results and the reporting of the problems found. * Create a document that describes the procedure to run test cases using the external whitelist in a desktop. * Update the document for the server that was created in the previous cycle. This includes, for example, adding a section about how to troubleshoot problems. For instance, what to do if a test case doesn't work as expected, the test results cannot be submitted, etc. * Create training material for TAMs and customers, so that they can get some hands-on experience before certifying a device for a given release for the first time. * Provide guidelines either in the documentation or the test case description to configure the environment properly when full automation isn't attainable. == Whitelist coverage == The different set of test cases between the internal and the external whitelist, causes that the coverage achieved depends on the whitelist executed when it shouldn't be the case. * Review both whitelists and make sure that they provide the same amount of coverage. * When the improvements on test case automation aren't enough to get the desired coverage, create alternative and easy to configure test cases that can be used to test the same capability/feature in a different environment. == User interface usability == The new Qt interface is a step forward in terms of having a modern interface that looks appealing to users. However, we have to make sure that it lives up to the expectations of testers. * Review the interactions required to run test cases and solve any issue that prevents the tester from having a good experience that encourages collaboration and makes reporting problems easy. For example, look at the consistency of buttons when marking a test cases as passed/failed/skipped.

This blueprint is to discuss the work need to add MySQL Utilities package to Debian and Ubuntu.

Are there any infrastructure changes would help the Ubuntu Flavors and their communities with development and test?

Specification for a set of policies and settings important for desktop lockdown.

With the inclusion of Samba4, Ubuntu still lacks of a graphical interface to manage a domain directory, including LDAP, Samba, DHCP, DNS, etc. For administrators coming from the Windows world a graphical interface is a must. In the past some tools like SWAT did this job but they have become obsolete with the release of Samba4 that needs a more complex setup. Zentyal is currently the only interface on Ubuntu that can manage and maintain synchronised Samba4 and OpenLDAP. We will discuss further improvements on this and integration with Ubuntu default components.

Kernel Stable Release Updates (SRUs) are tested by the certification team in search of possible regressions or bugs that may affect certified systems. These tests have to be performed in sync with the SRU release cadence, and in order not to hold up the SRU's release, they need to be done within a tight schedule, so they entirely consist of automated tests, to provide the response times and scalability the SRU process requires. Due to its nature, SRU testing would benefit from as many tests as possible, but always with the constraint that they be automated or, at most, require a human to review collected data in bulk. Tests that require interactive verification or human action are to be avoided. To enhance the value provided by SRU testing, we need to both add new tests, and improve the existing ones, based on input from the Kernel team about the areas that traditionally give the most trouble, and possible ways to test for bugs or regressions. == Improving the test development process == From inception to actual implementation in real SRU runs, tests may take up to 4 months to actually start being run. This diminishes the value and means that the number of tests that can be implemented per cycle is very small. The test development process needs to be described, analyzed and reengineered with the goal of reducing the turnaround time for new tests as much as possible. == Improving coverage in existing areas == Coverage has been improved in e.g. wireless testing, but some other areas, such as graphics and audio, can still use some improvement. Consulting with experts on these areas as to which tests would be useful to have, and implementing them (ideally with the new process so we can start seeing results as soon as possible). == Automating plugging/unplugging of devices == Coming up with a solution that can automate traditionally manual actions (such as USB, memory card, external video and FireWire insertion or removal). This would enable automation of these high-interest tests, and open up new areas for SRU testing. == Benefits from this blueprint == The certification team will benefit from an ability to develop reliable tests more quickly, by being able to respond to requests from other teams, as well as having techniques for automating physical interaction which will allow fully automatic and more comprehensive testing while maintaining scalability. The kernel team will benefit from wider testing, able to catch more bugs and regressions in sync with the SRU cadence, and an increase in the number of test results the certification team will provide. List of possible tests: https://docs.google.com/spreadsheet/pub?key=0AhMEQ8F2hKQOdC1Vd0RGWllLa3R1ZXNkbldsaDJvaWc&output=html

Present current design of user namespace, and discuss likely upstreaming dates and possible early inclusion in our kernel.

Planned updates including Greeter as the Lock Screen, flicker free transitions, confirmation dialogue, morphing login box, drop-down menus and back button.

The purpose of blueprint will keep track of the work needed to be done for integrating the Folsom release into Quantal.

The purpose of this blueprint is to keep track of work that needs to be done in order to improve our Openstack QA lab.

Today, whether you are developing a web service, website or a web application, a vast majority of these are required to sustain a satisfactory level of service and/or user experience to a large capacity of users/clients. There is a wide range of performance challenges that today's developer needs to meet and overcome. What will be covered: * In this workshop we will explore the various performance challenges and solutions available today for developers to overcome these challenges and build failure resilient applications by using open source tools (e.g. Apache JMeter) running on Ubuntu servers. * This 1 hour workshop will cover end-to-end the process of building a test scenario and successfully running an extra large capacity load test. A user attending this workshop can expect to gain the knowledge of how to easily run a load test using open source tools on Ubuntu. Topics that will be covered include: * Today's performance challenges - what to look for * Available tools for super easy performance testing * "Hello World" in Performance Testing - creating a test script in 10 minutes using Apache JMeter * Run an extra large capacity test * Answering performance and JMeter related questions. User can ask any level of question and get answered.

It would be useful to discuss where the Ubuntu QA team is moving with its focus on tools and practices and how it applies to upstream projects. It would be especially interesting to see how these tools can benefit upstream projects with regard to cross-platform Linux distributions support.

The Stack Overflow affiliated website Askubuntu.com has yielded volumes of user information and valuable direct community involvement. It's likely worth the effort to pay special attention to this resource particularly with upcoming future challanges requiring informing of users confused by Unity, trying out Ubuntu TV or server cloud features, or installing Ubuntu on a tablet device, for example. Discussion will likely involve new concepts to better serve question askers and answer providers alike. Automation of question keyword filtering and responsible person notification, search machine optimization, topic separation according to UX, application development, and API enrichment are subtopic candidates.

OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined "forwarding instruction set". -http://www.openflow.org/ There are several FOSS implementations of openflow controllers. This session is intended to review the list and choose one for packaging in universe. Our criteria will be based on language choice, quality, development community health, and OpenStack Quantum support. The current list for review are: 1) NOX[1] - Created by Nicira, supporting C++. No quantum plugin. Not to be confused with "NOX classic" an older implementation supporting both C++/Python. 2) POX[2] - Same as NOX, but younger of the two projects and supports Python. No quantum plugin. 3) Beacon[3] - Research project written in Java by David Erickson, a PhD candidate at Stanford. No quantum plugin. 4) Floodlight[5] - Written in Java and recently opensourced by Big Switch Networks as "the foundation of a commercial controller product". In terms of Quantum plugins, Big Switch Networks stated on the project mailing list[6] that it wasn't in *their* roadmap, but encouraged the community to do it, e.g.: "...Big Switch also has a quantum plugin but its based on functionality not present in Floodlight on this point." 5) Trema[7] - Supports Ruby and C. Developed out of Japan according to their twitter feed[8]. NEC has created a Quantum plugin[9] that works with Trema, as well as their commercial OpenFlow controller. 6) RYU[10] - Written in Python by NTT, who have also directly contributed a Quantum plugin[11]. [1] http://www.noxrepo.org/nox/about-nox/ [2] http://www.noxrepo.org/pox/about-pox/ [3] https://openflow.stanford.edu/display/Beacon/Home [4] http://www.linkedin.com/pub/david-erickson/3/89b/166 [5] http://floodlight.openflowhub.org/ [6] http://bit.ly/K1w69p [7] http://trema.github.com/trema/ [8] http://twitter.com/#!/trema_news [9] https://github.com/nec-openstack/quantum-openflow-plugin [10] http://www.osrg.net/ryu/ [11] https://github.com/openstack/quantum/tree/master/quantum/plugins/ryu

We have had Jockey for quite a while now to perform the installation of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. fglrx-updates), third-party (e. g. from openprinting.org) drivers. However, I feel that this needs some refreshing: * The code base of Jockey is quite complex, it was meant for a lot more stuff than we are actually using it for. We also came up with simpler ways of mapping hardware to packages, mostly with additional tags in the apt package lists. We also have a more upstream friendly API in PackageKit/aptdaemon now to do this kind of thing. We can simplify the jockey code base and backend logic a lot (up to the extend of completely dropping it) by making full use of above new technologies and dropping the extra features we don't use. The exception is the openprinting.org detection, but that could go into system-config-printer or python-cups directly. * We install some drivers (like Broadcom wifi) straight from Ubiquity now, which certainly makes sense for devices where there is no free alternative. For the others (e. g. NVidia) we pop up a notification and offer to install them. I'd like to walk through the current UI and discuss how this could be made more steamlined and less confusing (e. g. for NVidia it can potentially offer 6 different drivers for you!) * We might consider merging the jockey UI functionality, which is mostly a shallow GUI around "install that package" now) into software-center, control-center, or something similar to the codec installer. I'd again appreciate if someone from the design team could participate in that (hello Matthew!).

Session to discuss and collect community wishlist for kvm and related packages

Here we go again!

Planning what the Accessibility Community Team is going to do for the next cycle. We were over ambitious last cycle, so it's time to pare down and look at what's realistic for this next cycle.

Discuss cleaning old kernels for the user