Action items from UDS Barcelona

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.

More Karmic plans

The Jaunty development cycle was a hectic, pulsating (no pun intended) ride, and Karmic's looks to be just as vigourous! Here are my objectives for 9.10:

Audio:

Enable power-saving by default for HDA controllers - after fifteen seconds, power down the HDA controller to squeeze some juice for those transpacific flights. I'll be calling for testers shortly, but I'm most interested in resolving anomalies after the controller powers back up. You can already test this today if you're using karmic's kernel or a git snapshot of alsa-driver:
echo options snd-hda-intel power_save=15|sudo tee -a /etc/modprobe.d/test_power_save.conf

Offer snapshots of ALSA drivers - transition alsa-driver stable and unstable snapshots to use DKMS, and build daily debs in an audio-specific PPA (to be established)

Offer snapshots of PulseAudio - transition to weekly snapshots of git HEAD of upstream master, and build debs in above PPA

Streamline troubleshooting - offer GUI method for resetting stream volume and sink

General packaging:

Resume mentoring - already held two classroom tutorials. We need to use #ubuntu-classroom more effectively

Set periodic runs of piuparts/autopkgtest - determine which subset(s) of main and universe and make sense; enhance any existing build harnesses. See also where LDTP fits

Outreach:

Engage middle-schoolers, high-schoolers, itinerant workers in FOSS

Jaunty release party; more Karmic brainstorming

We're having a Jaunty release party in Washington, DC.

I'd also like thoughts on how to make resolving bugs like this one more transparent, err, easier, to the casual user. (Sure, I could have picked any one from thousands on Launchpad.) Matt Z has already contributed apport hooks to facilitate the process, but we have a long way to go still. (Please don't castigate or indulge in overzealousness in the comments.)

Further down the rabbit hole

Craig, emotional bug reporting inevitably does a disservice to bug reporters and the people working to fix bugs alike. Reporters tend to omit necessary information; triagers and developers tend to ignore vitriolic (and often misled and/or uninformed) rants. Neither helps advance the state of FOSS. While I empathize with your (and nearly everyone else's) frustration with audio in Jaunty, there's no easy solution to the mess [PDF]. Many people blame Hardy's poor PulseAudio integration, and they are well placed to decry the missing changes to /etc/pulse/default.pa to allow most non-Free applications to play nicely. You specifically call out "functional" testing in the QA process, but are you actively involved in said QA process?

There are a shedload of shortcomings in Ubuntu related to audio. E.g., ubuntu-bug/apport could be taught to use alsa-info.sh (which isn't in Ubuntu Jaunty's alsa-driver source for various reasons but will be in Karmic's) behind the scenes; a standing FeatureFreeze exception similar to the GNOME desktop's could be requested and granted for ALSA-Lib and PulseAudio; linux's generic configuration could be "better" tweaked for desktop interactivity - and those are by no means comprehensive. However, each comes with an opportunity cost. Every single one of us needs to do a better job of working upstream, because throwing a tantrum in front of volunteers accomplishes little.

Lessons learned at Jaunty Beta

Jaunty Beta has been incredible in countably infinite ways:

Good:

• iotop has pinpointed gconf doing silly things after distribution upgrades;
• linux is queued for upload with backported patches to resolve the "OMG PULSEAUDIO SUCKS" bugs;
• VirtualBox has proven to be invaluable for testing;

Bad:

• The audio stack has been in constant flux since Jaunty opened for development. Apologies for not having been able to provide a smoother, better engineered experience, and thanks for sticking with me through the stuttering, clicking, popping, and crashing...
  
• I have been reminded constantly that we, as a community, are failing to support our upstreams and volunteers. During last December's UDS in Mountain View, I took a moment to thank Graham Binns for his thankless work on the Launchpad bug tracker. There have been scattered attempts of "thank a developer" a day. Really, we need to be doing that every chance we have! So - thank you, fellow volunteers and developers. I really couldn't keep plugging away at FOSS without you gals and guys.
• It is fashionable to hate on Ubuntu and Canonical. I am not an apologist for either, but I do choose to spend my time primarily in Ubuntu. Practically, I do not have enough cycles to treat all upstreams equally. That sucks. Apologies to Debian, PulseAudio, and Linux, to name a few.
  

Call for testers

If you're as annoyed as I am with Jaunty's PulseAudio instability, behold, there is light at the end of the tunnel. If you're running 64-bit, please test the kernel at http://kernel.ubuntu.com/~dtchen/ and let me know how the stability of PulseAudio fares. If there is enough interest, I'll work on building 32-bit.

Edit: 32-bit is now available.

Triaging bugs in Ubuntu, or How Not To Tee Off The Most Important Person: Yourself

Colin Watson and numerous others have written about the seemingly sad state of bug triaging in Ubuntu. Many of the criticisms are spot-on. For the protocol (whatever that is) to be effective in actually resolving the issues reported in bugs, we need a technically competent swarm. How might a community-ordered distribution like Ubuntu go about growing such ranks? After all, the topic of resource constraints is by no means unique to Ubuntu tasks. I remember discussing it in the inaugural MOTU Council, and mentoring was incorporated as part of the new developer protocol.

Mentoring seems to be an underused feature in Launchpad for Ubuntu bugs. I propose that prospective members of the Bug Control team participate as mentees. (I do not wish to quantify a metric for determining whether such mentees would then be "fit" to join the team.)

Consider this post a call to fellow developers to offer mentorship: go ahead and choose the "Offer Mentorship" link at the trailing vertical edge of any bug report in Launchpad. For what it's worth, consider me a mentor for any audio-related bug. (And yes, that next post about Linux is forthcoming.)