As usual, the Ubuntu Developers Summit was a whirlwind, and I returned to the States enthusiastic about making Karmic a better user experience.
On the audio front, a slew of bugs have been resolved in Karmic simply by upgrading the entire stack. I led a plenary session during UDS focused on the travails of audio in Linux [OpenOffice.org presentation] with emphasis on how they affect Ubuntu and its remixes. Soon Luke and I will be offering snapshot builds in a dedicated audio PPA of alsa-driver-stable (daily), alsa-driver-unstable (daily), and pulseaudio (weekly). These pristine builds will contain only minimal packaging bits to facilitate debugging with respective upstreams. The availability of test builds of PulseAudio will make it easier to ship the most recent stable version in Karmic.
Roderick Greening and I will be testing GStreamer with PulseAudio on Kubuntu as part of the effort to streamline the audio stack. There will be a separate PPA for these packages.
Glitch-free PulseAudio likely will not be enabled in Karmic. There is insufficient traction in changing kernel configuration options, and we will all need to evaluate how those configurations affect other objectives (e.g., improved battery life).
As part of an improved battery life objective, powering down HDA controller amps when no sound is being played has already been enabled. The mailing list post covers possible regressions and how to track development with your experiences.
On the community front, something that has plagued the distribution process-wise is the heavyweight handling of patches from contributors. Patches, even URLs to them, often languish in Launchpad despite being tagged as containing patches. Both drive-by contributions and fully Debianised/Ubuntuised debdiffs suffer this same fate. I've taken on the task of making sure the process for people not immersed in the Ubuntu development model is more akin to a front office or reception similar to MOTU mentorship. Instead of expecting new contributors to follow the distribution's development model, a new Launchpad group, ubuntu-reviewers, with an associated mailing list, will be responsible for taking posted references to git changesets, patch URLs, etc., converting them into usable debdiffs for the appropriate Ubuntu release(s), and subscribing the appropriate component sponsor group. For example, if you find a bugfix for a package, you could send an e-mail to the mailing list for said review group. You could also file a bug using ubuntu-bug/Launchpad, clearly state the URL to the patch, and subscribe the review group.
While the administrative work is in progress (e.g., name of the Launchpad group), the goal is straightforward: involve as many contributors as possible without bogging them down in, well, administrivia.
