On Thu, Oct 8, 2009 at 8:14 AM, Vincenzo Ciancia <cian...@di.unipi.it> wrote: > The real problem that nobody seemed ever to be getting is that when you > introduce huge regressions, then you probably should 1) either not > distribute the software yet 2) or put more energy into bug fixing for > the particular software, or at least have strong, or 3) have convincing > reasons for forcing people to "enjoy" the regressions while they could > as well live happily with the previously used one, or 4) make it easy > for people to try the new solution, and if it fails, revert to the old
All valid points, but: (1) is a catch-22: software does not get fixed if no one uses it. You need real, difficult bugs to be reported, i.e., real testing. (2) requires that clueful people dedicate resources. Resources are not just economic. As I've stated previously, finding people who know the stack intimately is nontrivial. (4) has always been possible. It has always been easy to use PulseAudio and discover its integration deficiencies. It has not always been easy to disable PulseAudio, but it certainly remains straightforward for a savvy user: touch ~/.pulse_a11y_nostart echo autospawn = no|tee -a ~/.pulse/client.conf killall pulseaudio > video calls. I never succeded in having it work for voice/video. And it > is so badly broken in other areas I really wonder how you all can be so > blind. You seem to use "you all" as if you can't effect change within the source development. > Asking users to start contributing proves that there is no sufficient > manpower to fix bugs. But perhaps people could live without the new > software and related regressions? Now in the case of pulseaudio, for me, There has always been a manpower issue. Realistically, people need to step up. I'm a bit tired of spending all my free time doing this for naught. Living without PulseAudio is possible, but which bugs would you prioritize? For instance, how easily would you find bugs in alsa-lib and linux if you don't have hard but useful test cases? Empirically, not easily at all. Significant bugs in both alsa-lib and linux sat undiscovered and unfixed for _eleven years_ before PulseAudio finally revealed them. > But are there experimetnal measurements of the impact the introduction > of pulseaudio had in hardy on users? Empirically, I saw that it broke > skype for everybody I knew. No need for experimental; just look at all the bug reports filed affecting flashplugin-nonfree, nspluginwrapper, firefox-3.0, alsa-lib, and pulseaudio. The sad thing is that we could have shipped a two-line change to /etc/pulse/default.pa that would have alleviated nearly all of the (users') showstoppers. The change remains in my pulseaudio/hardy bzr branch. Skype fundamentally misused the alsa-lib API. PulseAudio "broke" Skype is a horrible non-example. -Dan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
