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