[Fedora-music-list] audio/media related reports to bugzilla.redhat.com ignored?

[David Timms]

On 09/07/10 05:10, Niels Mayer wrote:
> For audio/media related apps and issues reported on
> bugzilla.redhat.com , this is the pattern: bugs get filed, they're
> never acknowledged && totally ignored. Eventually people stop filing
> bug reports as it ends up being a waste of time and the quality of the
> distro goes down as result....
Hi fellow fedora music list users,

As you can probably imagine, open source developers and maintainers
generally work for free, in their own time. Many Fedora packagers, have
lots of packages to look after. Even for those people (like myself) who
have only 10 packages, it takes a serious amount of time to package
applications to be of a useful quality for Fedora. And that is just to
get the packaging technical side done, and doesn't include the detailed
QA that could or should be done on actual application operation if there
was more manpower.

You might like to take a look a Fedora's Bugzapper/ QA process at:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

As you note, many submitted bugz involving audio are still in their
"new" state. This really just means that no one has had time to look at
them at all yet.

For ones I'm interested in, reproducibility is the key problem. Either
there is no information on "how" to cause the issue, or when followed,
the same bug does not occur. An extra challenge for me working on audio
apps is that my new hardware has audio issues during record attempts,
that means that even if I do get a crash, it's entirely different from
the crash reported ;-)

In this case, I can't reliably confirm the crash, nor can I say that it
isn't reproducible; with more info or different hardware, it might be...
I prefer not to say this isn't a problem (by closing the bug).

Where to from here ?

People. With time. And you can be one of them !

There are many areas to work on, whatever interests you:
- bugzapping 1: take a look at audio bugz filed by other people and try
to reproduce the same fault. If you can, move the bug into 'triaged'
state. Otherwise comment that with audio hardware X, version Y, this was
not reproducible. Make it a personal challenge that for each bug you
submit, you also triage another bug !

- bugzapping 2: for a triaged bug, retest with the latest version from
-updates-testing or rawhide, is it still reproducible (state the
version). Still have time ? Rebuild the package with the latest upstream
release version (or even CVS), and retest. Place advice that this is or
isn't fixed in the upstream version in the bug, so that the package
maintainer can see that version Z specifically resolves this issue.

- active packaging: well, we can see that you spend a lot of time
playing with audio apps, including compiling from source, or using rpms
from other distros. It isn't much of a jump to knocking existing rpm
specs into shape (by reading the packaging guidelines, and asking google
/ questions). Create the package review request, let us know on the
music list that you have a package ready to go, and we'll do what we can
to take it from there.

- active bug fixing: get intimate with the upstream code base, work out
whats happening, how to fix it, post patches to the upstream project,
test the result.

- documentation: add pages within your personal space on the fedora wiki
dedicated to specific tasks...

Anyway, perhaps some of this has been useful, or even inspirational, and
we look forward to many new contributors crossing the small divide from
open source consumer into creator / producer ;-)  (Sorry if you already
have).

Cheers, David Timms.