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. _______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
