Last edited · 5 revisions  

 


How to report an error

  1. Provide a short and precise title ("HELP!" is not what we have in mind here)
    • The title may be the most important part of the report as it is read the most. If you want help, do your best to come up with a title that people want to read.
  2. Provide a concise description, including the steps needed to reproduce the error. If needed, you can suggest the behavior that you were expecting to see.
    • Bug hunting is time consuming work. If you want a bug to get fixed, make sure you give enough information to reproduce the problem.
    • What did you do?
    • Was there something different between when the program works and when it doesn't?
    • How did you expect the program to behave?
    • Can you describe the audio issue? If not, can you enclose or attach a recording of the audio?
  3. Provide environment information about your setup
    • Hardware platform (i.e. ARM, X86, VPS, Docker, etc.)
    • Operating system and version (i.e. uname -a). If it is a particular distribution (Ubuntu, Debian, Arch, etc.), say so.
  4. Note the application version and the build timestamp
    • The version and build timestamp are found in the log file when the app is launched.
    • Please make sure you are not reporting a bug that has already been fixed!
  5. Provide your actual configuration files (redacted of personal and password information)
    • In order to reproduce the issue, we will need to re-create your environment.  Your configuration files are the key element.
    • MMDVM_Bridge.ini, DVSwitch.ini and Analog_Bridge.ini are needed at a bare minimum.
    • Please do not just paste config files in the message, enclose/attach them. It makes our job easier.
    • You may have multiple versions of a file (transcoders, for instance, have multiple Analog_Bridge.ini files)
  6. Provide your log files
    • Log files are the other artifact that helps us debug an issue.
    • What did the app do with a specific input?
    • Was there an error? What happened before the error occurred?  The log files tell us this and more.
    • Your log files may appear in several directories. There are default locations, but your ini files can change that.
    • You should enclose/attach your log files in the message
    • The log level is important to our debugging efforts. For most things, a logLevel of 2 is sufficient detail to debug the problem.
    • Sometimes a very verbose version may be asked for and you would need to set the logLevel to 1.
  7. PLEASE avoid sending screenshots
  8. Follow up
    • Once a developer says a bug has been fixed, please re-test the issue and make sure it REALLY has been fixed.
    • Did we fix the bug and cause 3 more? Oops!