This meeting is to brainstorm on the current release process used Oneiric, what worked and what didn't, and ways they can be improved for Precise.

* What can we expect from upstream this cycle? * Can we automate packaging more? * Worth using UDD branches? * Revise Ninja processes to be more efficient with macro upstream packages * Point releases as stable release updates?

which ibus applet to use?

We want to discuss the plans to start growing an Ubuntu app developer community

We'll be presenting new features planned for 12.04 and hopefully we will be looking for support to implement the scrollbars on different toolkits.

The design team is planning to run design "theater" sessions at UDS. As a general rule, the design works on Canonical projects. It is our opportunity and pleasure during UDS to dedicate some time to help with other free open source software. What is Design Theater? During these sessions, we explore a design issue that you submit to us and take it through our design process. Why should you come? We hope to take you through the design process with real life examples, so we can share our design thinking and problem solving with you and propose any solution you might like. How can you participate? You have a choice: As an observer: come an look over our shoulders as we discuss applications design issues and join in the discussion. As a participant: bring us your free software application for which you need design guidance or user experience input. We'll try to fix it for you and show you how to approach this particular problem the design way. If you are thinking of joining us as a participant, please, send us your design question in advance, if you can, so we can get the ball rolling. Send it to: charline.poirier@canonical .com Who will be there from the Design team? At each session, you will find a user researcher, a brand designer, a user experience specialist, an interaction designer and a visual designer, Come find about our process and challenge us!

In order to consider Qt a recommended choice for Ubuntu app development, we need: - Better integration of the Qt development tools with Ubuntu-specific processes and tools, such as packaging, bzr, Launchpad... - Ability to access the Ubuntu platform APIs from Qt. - Ensure the packaged Qt development tools are in shape We'd like to discuss what needs to be done and a roadmap for this work.

= Summary = We have lots of ideas for changes we'd like to make to Upstart this cycle. This blueprint will outline those features at a relatively high level. Ideas (highly incomplete list currently): - Fully segregated SystemV / Upstart system shutdown - Introduce "setuid" and "setgid" stanzas to allow jobs to run as a different user/group. - Enable user jobs (a simple change to a dbus config file). = Desired Outcome = - A better understanding of those Upstart features you'd like us to work on - A feel for the relative importance of each feature which we'll factor into our plans to allow us to prioritise the work.

With our switch to tb this cycle we let the default installation without a calendering solution. We should decide if we need one by default. We might not need a full client ui but we should probably at least have a way to subscribe to a remote calendar to have desktop integration and notifications working

We'd like the tutorials section of the app developer site to grow with interesting content for Ubuntu app developers. In this session we'll discuss and come up with a plan to do that. Ideas: - Brainstorming of topics where we need tutorials - Structure the list of topics in a shortlist of essential ones - Reach out to the community to assign at least one person to a tutorial - Set up editorial permissions and process in place on the app developer site

Present current state of OpenJDK on ARM for the p-series

Followup on https://blueprints.launchpad.net/launchpad/+spec/other-o-bug-lifecycle, reviewing results of developer survey, and discussing proposed changes to bug states and workflows.

QA Requirements for submitting automated tests into the QA lab - Test outputs - Resources - Jenkins

The QA CoP would like to see the following data points available for reporting on the default interface for the Lauchpad Results site. Requirements for Test Results Dashboard Testrun: Regressions (previously passed now failed) https://dev.launchpad.net/Testing#Iterating%20with%20testrepository Fixes (previously failed now passed) e.g. http://qa-reports.meego.com/1.3/Core/Auto/Netbook Tag test runs Show test Results by categories/suite if applicable (see http://qa-reports.meego.com/1.3/Core/Sanity/Netbook/3173#detailed_results) Plotting of results (benchmark, performance, trend reporting), based on query parameters Hardware target information (structured, like devices, and unstructured, like log files as attachments) Software versions (packages, distro, bios) TestResult Test case Status (Pass, Fail, Skip, Blocked, Unknown, Untested, Unsupported, Error, Bug) Test case run time (Elapsed(Min), Time Stamp(Milisecond)) Test case output (stdout, stderr, status code, log files) Test case result(s)/data/measurement(s) Add comments/bugs from the interface Offline submission from local file (default protocol with result2launchpad) (DONE) Generation of regression test files (whitelists for checkbox) Advanced search of cases (Elapsed time, recently failed, hardware used, tags)

It would be nice to be able to optionally run Wayland in 12.04 to try out the technology. This will involve: - Modifying LightDM to support Wayland - Writing a Wayland compositor - Running an X server that writes to the compositor - Making it easy to enable this - Disclaiming all responsibility This would be a low priority task.

There is a huge interest in getting involved in Ubuntu development. We want to better reach out to everybody who is interested. The recent survey data will probably help with the discussion of this.

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS.  * What is the best way to distribute the updated X stack?  * Will this be an opt-in change for upgraders? If so, how will the upgrader need to be changed to properly guide the user in making a choice?  * For consistency, what version naming scheme should be used for these package updates?  * Should we limit it to just the serverside portion of the X stack? (I.e. omit libX11, etc. to avoid breakage to client apps) * For certain graphics cards, there is a possibility that driver support could be dropped in future kernel and X combinations; the upgrader will need to be aware of this and not suggest the upgrade if it won't work, or perhaps make them aware of the risks or known-regressions they'll endure if they wish to proceed anyway.  * Should a way be provided to enable the user to back out the changes? If so, how should that be implemented?  * How tightly should the kernel / X package versions be kept? I.e. should we discourage or permit old-kernel/new-X and/or new-kernel/old-X setups. (If we permit these combinations it gives user flexibility but imposes a larger testing impact).

Translations roundtable discussion where to fit all other topics not covered in dedicated sessions

Improve finger print authentication in Ubuntu

A first set of metrics are to be put in place during Precise. This session is to discuss about code coverage and test escape analysis.

Hacking on summit.ubuntu.com while everyone is together.