First session of the week, meet the team Review Oneiric

Discussion about how we build experiences in Ubuntu from the design to implementation level.

Enable jack detection features in the "Sound Settings" page of GNOME Volume Control, and redesign the UI to be more user friendly (present "Port"/"Connector" as primary object, merge hardware tab into Input/Output tabs).

This will detail the plan for the Council for loco teams, approval, any new guidance pages to be written, goals to help get locoteams more involved in the community

Mike Sweet intends to remove the filters which are not used by Mac OS X from the CUPS upstream package: http://www.cups.org/str.php?L3930 We have agreed on this on the last OpenPrinting Summit and the filters will be continued and hosted by OpenPrinting. In addition, the filters for the PDF printing workflow will not be adopted by CUPS but joined with the CUPS filters we overtake. All Linux distributions would have to include this new CUPS filters package then to get CUPS continuing to work and have the same feature set as before. Due to the fact that this package will use the PDF workflow by default and that all major desktop applications send their print jobs already in PDF, this will complete the implementation of PDF as standard print job format in all distros (if they do not patch against the PDF workflow). See also my updated web page: https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat This will also clean our heavily patched CUPS package somewhat. We need a name for this new upstream package. Should we call it simply "cups-filters"? Or "op-cups-filters"? Or do we rename Foomatic to openprinting and have the packages - openprinting-db - openprinting-db-nonfree - openprinting-db-engine - openprinting-rip - openprinting-cups-filters Note that we keep foomatic-rip/openprinting-rip separate from the CUPS filters as this filter is a universal filter which also works with many other printing systems. Another decision to make is whether we really should maintain all the filters which get over to us from CUPS or whether we should discontinue some. The filter set will contain "imageto..." and "textto..." filters which are not made use of by the usual desktop applications, they send all PDF (and some send PostScript). Alternatively, these filters could be made optional. Usually these are decisions to be made by upstream, in this case OpenPrinting, but in this session I want to have some pre-discussion from the distribution point of view, so that when this new upstream project gets created it will be created with the distro's needs in mind.

How to increase theming consistency and how to properly style widgets and user interfaces

* Nepomuk by default? * KMail2/Akonadi * Akonadi off by default (calendar integration)? * QT_ACCESSIBILITY * LightDM?

Ask Ubuntu is an up-and-coming source of for Q&A in the Ubuntu Community - lets figure out how to integrate it into the community at large!

 * LTS?  * How to maintain quality * KDE papercuts? * starship troopers - whit?

Python plans for 12.04 LTS: Python 3.2 and 2.7 only. We dropped 3.1 in Oneiric and 2.6 in Precise. For 12.04 the goal is at least one desktop application destined for the default installation (i.e. CD images) to be ported to Python 3. Long term (14.04 LTS), we want Python 3.2 only on the CD, with 2.7 still available in main.

Thomas Senyk, Johanness Zellner, and Adam Weinrich from the Nokia Qt team will be at UDS to answer any questions and discuss topics such as the Qt roadmap. Thomas and Johannes come from the Professional Services area and are paricularly knowledgeable on on how Qt is used in embedded space.

We've had useful discussions about refactoring flash-kernel in the past, but they've not not (yet) come to fruition. Where are we up to, and when can we get things done? Other packages and image builds should be depending on this work, but cannot yet.

Defect Analysts have hundreds, if not thousands, of bug reports at which they could be looking. Their dashboard will be a collection of the highest priority bugs to review on a daily basis with links to reports of bugs matching specific criteria.

This is where we will track the progress of Kubuntu Docs for the 12.04 LTS release of Precise Pangolin.

Despite current efforts Ubuntu still receives lots of bug reports without a package. These bugs are may be about serious issues in Ubuntu and are unlikely to be triaged. Using launchpadlib and text processing is it possible to determine what packages these bugs may be about? Are there other ways to determine the right package for them?

* Whither Kubuntu Mobile? * Plasma Active for the win?

We currently test Ubuntu Server ec2 AMI's at key milestones during the current development cycle; we should expand this todo daily testing of both the current development release and existing supported releases as well to provide assurance that Ubuntu Server cloud images are validated on ec2 and OpenStack.

As proposed in http://netsplit.com/2011/09/08/new-ubuntu-release-process/, we should create an unpublished release pocket that stands as the gateway to the regular development branch. From this branch unit tests will be run, code review and sign off will be checked, system integration tests will be run, and if any of these fail, the upload will not be copied to the development branch. We should unpack and run the unit tests for any reverse dependencies of the core libraries during package build in order to prevent breaking said dependencies with a dodgy upload. For example, an upload of GTK+ should trigger the unit tests for ubiquity and software-center to be run.

Currently, the teams are separate for en_AU Ubuntu packages and Launchpad-hosted packages. Due to the nature of en_AU not differing a lot from en_US, it may be beneficial to merge the two groups to consolidate efforts and membership.

Fregl tells us how to make it not crash

Plan the enhancements we want in apt for precise

There has been some very interesting ideas on improving the release process brought up by Scott James Remnant in his blog post, http://netsplit.com/2011/09/08/new-ubuntu-release-process/ Some of these we are looking at implementing for Precise (in other blueprints), other points need discussions as future options. This session is targetted to brainstorming what would be the impact of some of the more radical changes we're not going to fit into precise, since it is an LTS. Also what planning/blueprinting work should be done to assess if the process changes will improve the developer and user experience before the next cycle.

Discuss the next steps for cobbler to provide improvements, define level of maintainship, to make sure its continuum with Orchestra.

We'll review the activities about LoCo Testing, with the results from the Italian Team, and the Laptop testing project. We'll also discuss about the an idea in the Italian LoCo about a Triage Team with mentoring in native language and team's adoption.

Making our multi-monitor, dock and projector support better.

Following on discussions the past few months on ubuntu-devel, review the current workflow for accepting new packages into Ubuntu, with an eye to refinements or improvements we could make this cycle. Includes submission to Debian, Backports, REVU (and potential for switching to DebExpo), and ARB.

Complete and publish https://juju.ubuntu.com/AppArmor. (currently in draft)

Say cheese