SvxLink - Multi Purpose Voice Services System


Main Menu

SourceForge.net Logo

These pages are obsolete. Please use the Trac pages instead

Mailing lists

There is one way to get in contact with the SvxLink "community". That is through the mailing list. The address to the mailing list is svxlink-devel@lists.sourceforge.net. So, whatever your business is, please use the mailing list. Do NOT use EchoLink or direct e-mail to the author. The list is usually fairly low volume so don't be afraid to register.

There are a couple of reasons why only the mailing list should be used for support:

  • There are more people that can help. I only use Fedora Linux but there are people on the mailing list that have gotten SvxLink to work under other distributions.
  • Documentation. All mails sent to the mailing list get stored in the mailing list archive. A good way to find solutions to problems is to search the archive.
  • Other people subscribing to the mailing list might get helped by the discussion.

There is also another mailing list svxlink-announce@lists.sourceforge.net, which is even lower volume. Just a single mail per SvxLink release, which is not that often. If you join the svxlink-devel list there is no need to join the svxlink-announce list.

To subscribe to the mailing lists go here.

Reporting bugs

Bugs should be reported in the SourceForge bug tracker. It can be hard filing a good bug report. But I assure you, it is even harder to understand a bad bug report. So, if you find a bug, take the time to go through the steps below to make a good bug report.
  1. Search the bug tracker to see if your bug is already reported.
  2. Read the documentation thoroughly to verify that you have not misunderstood something. This includes the installation documentation, the svxlink server docs and the qtel docs, depending on what application you found the bug in.
  3. If possible, try to reproduce the bug. A way to reproduce the bug makes it much easier for the developer to find and fix the bug. If it is not possible to reproduce it, try to remember what happened right before the bug appeared. Include a detailed step by step instruction in the report of how to reproduce the bug.
  4. Write a bug report in the bug tracker. The bug report should include the following:
    • A detailed description of the bug. Do not just write "this feature does not work". Explain in what way it does not work. There can be many ways for a certain feature to fail.
    • If possible, describe how to reproduce the bug.
If these simple guide lines are followed, bugs will be found and fixed much faster.

Feature Requests

To request a new feature, use the SourceForge feature request tracker. If a feature is just requested via the mailing list it may easily be forgotten.

Copyright © 2003-2008 SM0SVX / Tobias Blomberg