Hello,
I am now working on an FAQ document for ser to avoid repeated questions on the mailing lists.
Many of you asked questions and got answers (or figured out the answers by themselves), if you feel that your question and answer should be included in the document, please send it to me in a private e-mail (don't reply to the list).
Any contributors are welcome, of course.
thanks, Jan.
I am now working on an FAQ document for ser to avoid repeated questions on the mailing lists.
Many of you asked questions and got answers (or figured out the answers by themselves), if you feel that your question and answer should be included in the document, please send it to me in a private e-mail (don't reply to the list).
Excellent.
As a first-time implementor of ser (and many many time implementor of lots of other Linux-based software over the last ten years), I've noticed that ser lacks helpful troubleshooting suggestions. That is also apparent from the many questions that have been posted. Reading the source code is not a reasonable/acceptable answer for 95% or more of the list.
I'm certainly not complaining, just suggesting that where possible, insert some "clearly stated" methods that would help diagnose implementation issues; and, if one follows those steps, the minimum info needed for any list posting asking for help.
Hello,
thanks for the suggestion. A bug reporting guideliness is here:
http://www.iptel.org/ser/bugs/
The page describes what to do and what information to send if anybody finds a bug. But maybe we should extend it and write some guideliness for people who are not sure if it is a bug or not.
Jan.
On 24-07 07:35, Rich Adamson wrote:
I am now working on an FAQ document for ser to avoid repeated questions on the mailing lists.
Many of you asked questions and got answers (or figured out the answers by themselves), if you feel that your question and answer should be included in the document, please send it to me in a private e-mail (don't reply to the list).
Excellent.
As a first-time implementor of ser (and many many time implementor of lots of other Linux-based software over the last ten years), I've noticed that ser lacks helpful troubleshooting suggestions. That is also apparent from the many questions that have been posted. Reading the source code is not a reasonable/acceptable answer for 95% or more of the list.
I'm certainly not complaining, just suggesting that where possible, insert some "clearly stated" methods that would help diagnose implementation issues; and, if one follows those steps, the minimum info needed for any list posting asking for help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Jan Janak -
Rich Adamson