Tobias Blomberg edited this page Jul 14, 2014 · 6 revisions

Getting Support

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 . So, whatever your business is, please use the mailing list. Do NOT use EchoLink or direct e-mail to the author. Private emails to the author is most often just ignored and thrown away. 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. You have a better chance of getting a quick answer.

  • 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.

  • I don’t have to answer the same questions over and over again.

There is also another mailing list, 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 GitHub issue tracking system. 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 issue 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 SvxLink 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 GitHub issue tracker. If a feature is just requested via the mailing list it may easily be forgotten.