Bug Submission Guidelines

When you discover a problem with Rosegarden, you can help us a great deal by performing the following steps when submitting bug reports. We realize that wading through these guidelines and then following them means more work for you, and we thank you in advance for taking the time to help us help you. For your part, it is a waste of your time to report an issue that no one will ever address, and for ours, it is more often than not a waste of our limited resources to follow up on reports that are not made in accordance with these guidelines.

Check for Similar Bugs

Submit a New Report

Once you have made a reasonable effort to ensure that you have discovered a new issue, then please continue with the following guidelines in mind.

Bug or Whine?

Is it a real bug, or do you just perceive it as a bug because the software you grew up on did things differently? Try to take Rosegarden on its own terms, and try to be realistic when deciding whether a particular complaint is a true bug or merely a feature request. If it's a feature request, don't try to sneak it onto the radar screen by branding it a bug. File it as a feature request. (See the guidelines at for more details.)

Bugs to Avoid

Build or installation problems make for particularly useless bug reports, and packaging problems are completely between you and your distro package maintainer(s). Please deal with these issues on the rosegarden-devel mailing list unless specifically asked to do otherwise.

Don't Be a Nobody

Please take the time to create a SourceForge account for yourself and use it for submitting and tracking your bug reports. The process of working out a solution to an issue and determining whether or not it is really fixed works best when you make yourself available for followup questions, and when you take an active interest in looking after your report. When you submit an issue as “nobody,” it automatically decreases the chances that anyone will ever address the problem you're reporting. Especially if your initial report is insufficient for us to determine exactly what the problem is in the first place.

Repeatability is Critical

A bug report that isn't repeatable is a waste of everyone's time. We realize that random things happen to random people at random times, and there are a number of real bugs we have been unable to puzzle out. Reporting things like “something went wrong with this file but I can't repeat it” is, sadly, a waste of your time and ours. We're certain something did indeed go wrong, but unless you can come up with a series of steps that cause the problem to manifest consistently, or at least frequently, then we will never be able to solve the problem, and it is pointless for us to try.

Having said that, “something went wrong with this file, and now when I do this, this happens” is perfectly acceptable. It is not as good as helping us determine how the file wound up in a bad state in the first place through a repeatable procedure, but if the bad state that you're in here and now leads on to consistent, repeatable results, it's a starting place, and problems like this can occasionally be solved.

Keep it Simple

You should make every effort to reduce a problem to the smallest, least complicated number of steps that can produce the bad result, and you should describe this procedure using as few words as possible. If you see something happen in the context of working on a complex composition, it is usually beneficial to save this work, set it aside, start a new file, and attempt to reproduce the problem in a controlled test environment, using the fewest steps possible. The shorter and more concise your report, the more likely it is that we will fix it. On the other hand, the longer and more complex your report, the more likely it is that we will skip over it time and again in favor of something easier to digest.

One Bug per Report

You should avoid the temptation to save yourself effort by combining different issues into one massive report. If there are three related aspects to the same overriding problem, then file each of these aspects separately. Under no circumstances should you ever file a “big bug list” report that reels off a laundry list of separate, unrelated issues.

Here are some good examples. These all relate to audio segments, but they are filed as distinct issues. They try to be to the point and repeatable.

Audio segment preview not aligned to tempo ruler

Removed audio segments still playing

audio segment selected after insert from file manager

It would have been terrible to combine them into one single “problems with audio segments” report instead, for example. Worse yet would have been something like this particularly egregious example of a bad bug report:

Juan's big list

This “big list” report was filed by one of us, so we well understand this temptation to lump things together like this. We have erred, but do as we say, not as we have done in a moment of wrong thinking.

Assigning a Category

You are free to try to determine what category your bug belongs to, and to assign it both to a category and to a particular developer. If you aren't sure what category to use, or which developer should handle this particular problem, then leaving it unassigned is perfectly acceptable, and preferable to assigning it incorrectly.

Producing a Stack Trace

If your bug involves a crash, then we will often come back and ask you to produce a stack trace if you didn't include one. In order to produce a useful trace from a standard user environment, you probably need to perform a few steps.

Go to a bash prompt (for example, run “Terminal Program (Konsole)” from the KDE menu) and then issue these commands to allow for the creation of core dumps, and to bypass the KDE bug handler:

ulimit -c unlimited
ulimit -H -c unlimited
export KDE_DEBUG=1

Now start rosegarden from this same command line, and reproduce the crash. You should now have a core file in your current directory. The core file is either named "core" or "core.<number>".

Now run “gdb” :

gdb rosegarden <core_file>

Now type “where” at the gdb prompt. Let the trace run to completion (or until it becomes apparent that it's in an infinite loop) and copy the results, then paste them into your report.


Your bugs should be submitted at the default priority of 5. They will be examined and assigned a new priority level in due course. See this chart for an explanation as to what various priority levels represent.