[LAU] Linux Audio podcast. episode003: commenting replies

J. Liles malnourite at gmail.com
Fri Aug 16 20:44:49 UTC 2013

On Fri, Aug 16, 2013 at 1:04 PM, Gabbe Nord <gabbe.nord at gmail.com> wrote:

> Yes, those are all fair points. What about the rest of the questions? Lets
> take the non-tools for example, as you're the author of them. With the
> non-tools, what do you think users (current as well as potential future
> ones) could do better in terms of bug reporting? How can a user (read: one
> without the ability or desire to learn how to code) contribute to the
> non-tools?

Bug reports are an entirely different problem. It's very hard to get a
quality bug report. They vary quite a bit. Often they are of the form "X
doesn't work properly". That's about as helpful as a handful of sand in the
eyes. It doesn't define 'properly', it doesn't explain how the user
determined that X doesn't meet that definition, it doesn't say what version
of X, where it was aquired, how it was built, on what system it was running
etc, and it is just lacking information in general. On the flip side, lots
of bug reports (this is especially true of automatically generated ones)
include pages and pages of backtraces and dumps, but don't give any other
context, such as what the user was trying to accomplish at the time (often
an extremely important piece of information!).

I have an article about how to prepare bug reports here:


But the issue has been covered at length elsewhere. Often the backtraces
etc are not even required, what is required is full disclosure on what the
user did and why--preferably without judgements or accusations (these often
backfire anyway, as a fair percentage of bugs can indeed be attributed to
user error, system configuration, or some other thing that is completely
outside the control of the developer).

Personally, I respond best to interesting ideas. If someone has a use case
for my software that I know I'll never personally need, but it's an
interesting an appropriate use case, I'm very likely to go ahead and put in
the time to implement it. Donations are always rewarding as well, they are
a very tangible way of saying 'thank you' and 'I like this'. Lots of people
will /say/ they love your work, but few will prove it by contibuting
(anything). As is true of most projects, I don't get many donations (that's
another topic entirely!), but I have had a few power users donate
considerable sums, and discussing changes with them feels a lot more like
collaboration than it does answering demands from those who contribute

I'm also very likley to accept patches, and willing to offer lots of help
understanding the code and design for those who want to extend the
software--even if it's in a direction that I don't agree with and wouldn't
merge into the mainline.

Testing is also appreciated. The best testing is acutal use and lots of bug
reports! It sucks to put out a 'stable' release and *then* get the bug

Hope some of this was helpful!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20130816/4c99a8eb/attachment.html>

More information about the Linux-audio-user mailing list