[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora too cutting edge?



Lennart Poettering wrote:
On Wed, 09.01.08 19:45, Hans de Goede (j w r degoede hhs nl) wrote:

Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL:

https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=

I don't think this BZ excerpt is any good as argument for your
point.

I agree with that to some part, I've recently been working on getting some pulseaudio problems in packages I maintain fixed, and when I ran that query I was a little bit amazed of the results.

Also I've been receiving quite a few bugs for some of my packages related to sound problems, and often these bugs are caused by people turning of pulseaudio (not on my advice!) but only turning it of partially, for example they often still have alsa-plugins-pulseaudio installed and enabled as default alsa sink.

So there are really problems with pulseaudio, or atleast people perceive some problems as being caused by pa, resulting in them turning pa off.

A big share of the bugs listed for PA are duplicates. BZ is
very good for burying people in vast amount of emails due to new or
updated bug reports. My main job is hacking on PA, not wading through
BZ. Which is why I tend to ignore bugzilla as good as I can and clean
it up only just before every release.

And I think this is bad, we need to nourish people who provide valuable feedback, not ignore them and let BZ tickets rot. Also see Jonathan Dieter reply for an example of why this is bad.

Why not reserve 30 minutes a day to respond to bug tickets, if you do this every day, keeping on top of things, then keeping BZ spam in track should be manageable.

Anyways after my recent bugfixing surrounding pulseaudio, I've already been thinking about trying to help out with pulseaudio, so as usual I'm willing to put my code where my mouth is and I'm hereby offering to do pulseaudio bug triaging for you. But pulseaudio is a complex beast, so I will be needing help from you. I can do the initial grunt work of filtering duplicates, filtering configuration errors and trying to make problems reproducable, but after that I will need help from you. Does this sound like a deal? And once I'm in a stadium where I need help, how do I reach you in such a way that you do respond in a reasonable time?

Thanks & Regards,

Hans


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]