It's Probably Our Fault

Some users are timid about submitting bugs. They might think that they "did" something to the program to cause it to misbehave. Don't be afraid! It probably is a bug, and if it's not that's ok too. In particular, the following are almost certainly signs of a bug:

  • Ardour crashed with "Illegal Operation" or segmentation fault
  • Ardour "freezes" and stops responding, or worse, causes your entire computer to "freeze".
  • Ardour won't do X correctly (record, open a session, etc.)

Other, less drastic but "weird" behavior could still be a bug. In particular, if a preferences-option doesn't do what it's supposed to do, a window doesn't act like it ought to, these are probably also bugs.

Before Making "Usability" Suggestions ...

... you should read this first.

How To Report A Bug

Ardour uses a system called Mantis to keep track of bugs. Mantis is easy to use and makes it easy to see how your bug has progressed, and when it is resolved.

Using the mailing list(s) or forums at ardour.org is the wrong way to report a bug. Your message will be almost always be ignored.

To report a bug, you first must create a Mantis account

We regret that for now, this login is separate and distinct from the one used on ardour.org.

Creating an account is easy and only requires a valid email address. Once you create your account, a password will be mailed to the email address you specified (it may sometimes take a while for get this email - the system where the tracker runs sometimes gets backed up sending outbound email). You only need to create an account once, and you can use it from then on out to report as many bugs as you can find.

Once you receive the password, you can enter a new bug report (new window). Be sure to add as many details as possible: if there's too few to reproduce the bug, it will be closed (no, we cannot read your mind!).

After you've submitted a bug, you can always go back and add more details. To do this, just go to Mantis's "Open and reported by me" link on the first page. You can then go into your bug and add additional "bugnotes". It is important to understand that when the bug is related to a particular session (i.e. it doesn't happen on other sessions), we need to get a copy of the session to be able to work on the bug: the conditions causing the bug may be very specific to your session - and recreating a similar session from a description is beyond what we can spend resources on.

Crashing Bugs

Bugs that crash Ardour are generally considered extremely serious and receive first priority in the queue (unless they are caused by things outside our control, in which case we try to document causes and workarounds). However, one of the problems with such bugs is that its often hard for developers to reproduce them, and so its important that you supply as much information as possible.

OS X Specific Information

If Ardour crashes and produces a crash report, then you should attach the contents of the crash log to your bug report as an attachment (or paste it directly into the "More Information" field).

But I Don't Have a Crash Report!

Most OS X systems are configured with the system crash reporter enabled. However, most modern OS X systems do not tend to show the crash log by default. If Ardour crashes on your system and you not get a report about it, open the Console (Applications > Utilities > Console) and look near the end of its contents. You will almost certainly see a line or two that mention the crash and the location of the crash log file.

Linux Specific Information

If you are reasonably comfortable dealing with the technical side of computers, you could help us debug ardour. Otherwise, just submit a bug report and consider hanging out on our IRC channel in case we need more information from you.

What Should I Expect Afterwards?

Bugs generally move through the following stages:

New
this means that it's in Mantis, but nobody has done anything with it (except perhaps read it)
Acknowledged
often, a new bug will become acknowledged just to that we can tell you that we've seen it and are looking into it. Sometimes, this stage will be skipped.
Feedback
This means that we need more information from you (or other people) about the bug you've reported.
Assigned
This means that someone has taken on the responsibility of fixing this particular bug. No time frame for a fix is implied by a bug entering this stage.
Resolved
This means that the developer who worked on the fix believes that the problem is solved. Bugs remain in state once they enter it, right up until you, the reporter of the bug, mark them ...
Closed
This means that the bug reporter (you) has confirmed that the bug is fixed. In general, we rely on reporters to close bugs they reported. You can do this at any time, which can be useful if a new version of Ardour fixes the bug as a side-effect without any developer explicitly attempting to fix the bug. Just mark it closed if this happens, with a note on what happened.

You will generally receive email notifying you of any change in a bug's status, or when any new bugnotes are added to the bug.

How Long?

The time it takes for a bug to be fixed is largely dependent on how elusive the bug is. In general, you should receive some form of acknowledgement that your bug has been received.

In particular, if you included instructions on how to repeat the bug (recommended), then you will likely get some responses that say "I (was/was not) able to reproduce the bug." If other people can reproduce the bug, this is good and it will probably get resolved quickly. If the bug isn't reproducible, it may be awhile before it is cause is tracked down.

If the bug cannot be reproduced from the instructions provided, a deveoper will usually leave it in "feedback", with a bugnote asking for more information. This is a request for you to add more details or answer questions from the developer. If we don't hear from you within a reasonable time period, we will move the bug to "resolved", where it will remain until (and if) you do.