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.
Do you have any sense of how many people consume testing ppa's. There seems to be an explosion of pristine upstream ppa's for testing across different portions of the software stack. The kernel guys are running a pristine dialy ppa as well. Will your audio PPA work with their kernel ppa? Is anyone keeping at least some aggregate stats on ppa usage to see what the uptake is actually like? Ideally how many people would you like to see using the pristine audio PPA?
ReplyDelete-jef
Why add gstreamer to KDE since it doesn't use it by default? In fact, isn't getting away from GStreamer the entire reason why KDE wrote Phonon? (Or are you thinking of using GStreamer as a Phonon plugin?)
ReplyDeleteJef, the Launchpad folks (#launchpad on irc.Freenode) are better aimed to answer your question regarding PPA usage. The audio PPA will complement the kernel team's pristine crack-o'-the-day PPA. Luke Y and I aim to guide testers of PulseAudio and ALSA specifically to resolve invocation and upgrade issues and hardware enablement issues, respectively. For audio purposes, the kernel team's pristine daily PPA will not be as "adventurous" as the audio PPA, the latter of which is designed to push and test fixes directly to ALSA (from which changesets can be cherry-picked into Ubuntu). The same repository will be useful for bleeding edge audio testers, but its purpose is for people experiencing problems with the audio stack in Ubuntu.
ReplyDeleteTanner, Phonon has a GStreamer backend, and Kubuntu is evaluating replacing the Xine backend with the GStreamer one. There are no plans to replace Phonon with GStreamer.
I'm looking forward to joining the ubuntu-reviewers group and hope to see an announcement soon!
ReplyDelete