On Thu, Jul 8, 2010 at 3:10 PM, 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.... > As David pointed out, most of us are like you guys, working on the project in our free time. There are a couple points you might want want to know: - Becoming a Fedora project contributor does not require programming knowledge other than bash scripting. There are many package maintainers who cannot debug code. - Many package maintainers maintain a large number of packages, and as you would expect some of these packages are not their favorite packages. They don't have the time to deal with all of the bug reports. I personally get all these ABRT crash reports from audio and nonaudio packages that I maintain. I am giving my best effort to keep in contact with the developers and the users to get the issues resolved but I still have many open bug reports, that I didn't get a chance to go over. We are trying the best we could provide, which is obviously not perfect. - I am not particularly happy with this new ABRT mechanism. It seems nice for a user. Click a few buttons, and you submit a crash. It sounds like you did your part of the job. However, the package maintainer might not be familiar with the codebase, might not even know the programming language the software is written with, or simply might not know how to program or debug. Even if the maintainer is a programmer, it will take time to decipher the code and find the source of error. It would be best if these crashes were reported upstream to the software developers, the people who actually wrote the code. Unfortunately, ABRT does not support this. And the way it is set up, I am afraid the users will be more reluctant to contact upstream developers, since they think they already submitted a bug report. - When you report a bug, think about why you are reporting it. There is some dis-functionality that is bugging you. But the bug is still there because it doesn't bug the package maintainer as much as it did you. Now, if this dis-functionality was bugging the package maintainer to the same extent, what would he do? He would contact the software developers and try to get things fixed. Therefore when you are submitting a programming bug, you are expecting the package maintainer to play the middle man, to carry the information back and forth between you and the developer. This is simply inefficient. - My own rule of thumb is, * Submit the bug to upstream developers if the bug is in the code. * Submit it to Fedora bugzilla if it is a packaging bug. * Submit it to Fedora bugzilla if I am not sure if it is a packaging bug or bug in the code, and ask the maintainer if I should submit this bug upstream. - The best bug reports (we don't get these very often but they are very very cool) are, when the user already submitted the bug upstream, and he got a patch that fixes the issue. When patches are submitted to Fedora bugzilla with the upstream reference, they will probably be included in packages very soon. My own couple of cents, Orcan _______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
