Subject: [ecasound] about submitting bug reports
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Sat Mar 03 2001 - 18:14:06 EET
I feel this is such an important issue that I better address it
On Fri, 2 Mar 2001, Marco Ciampa wrote:
> Ecasound is a GREAT piece of software and Kay is doing a great work
> in listening the lusers like me that complains about the bugs that are not
> able to fix by themself...
Now there's no need to apologize for, or downplay the importance of,
sending bug reports. Here's few "facts" about "ecasound development, bugs
and bug reports":
1. Bugs are good.
No matter what people say, software development is an iterative process.
One part of this is making errors and learning from them. Also, the amount
of bugs in a piece of software does not tell whether the software is good
or not. It just tells about the development stage. Completely separate
issues are whether it is appropriate to release a certain snapshot as a
commercial product, or whether the development has taken too much time to
achieve a certain stage.
With ecasound, everytime I touch the codebase, I'll release the results as
soon as possible. I don't see a reason for holding back features or fixes
just because I haven't tested them myself. So you will find bugs in
2. All bugs reports are welcome.
Some open-source/free-sw project have very strict bug-reporting policies.
Not so with ecasound. I'll happily accept _all_ feedback. Some bugs are so
easy to fix, that a 2-line bug report might be sufficient for me to locate
it and fix it. On the other hand, even the Perfect Bug Report might not be
enough if the problem is hard enough.
And of course, feel free to use common sense. It shouldn't come as a
suprise, that if you send me a polite, well written bug report with all
needed details included, it's more likely I fix the bug in no time. Then
again, if someone reports me that "Ecasound doesn't work.", that's fine
with me, but I won't spend much time with that specific report. ;)
Btw; a separate issue is where to send the reports. For instance, if you
are about to attach a 1MB trace file to your bug report, it's
better to send your report to me personally at email@example.com than
to the mailing list.
3. I don't guarantee a 24/7 service.
There are few cases where solving a specific ecasound problem has taken me
over half a year. So I've received a bug report mail, worked on it for 6
months, and then replied to the mail that problem is solved. In other
words, don't expect me (or anyone else) to reply to you (or fix the
problem) within a day/week/month/year. Your input is _valuable_ and
_appreaciated_ (!), but I just can't guarantee you anything...
4. There are no hidden testers.
Contrary to recent rumors, there is no hidden army of free-sw testers,
that goes through all free-sw packages in the world and test all their
features. In other words, it's just you and me making music (or whatever)
with ecasound. It is possible that there are some ecasound features (or
use scenarios), that nobody in the world has ever used. I might have
enabled it because it was possible and required no additional work, but
never managed to test the feature myself. So if you encounter problems,
please do report them.
Btw; Marco, it's Kai, not Kay... ;)
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Sat Mar 03 2001 - 17:30:14 EET