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
Go to our bug tracker at https://sourceforge.net/tracker/?group_id=4932&atid=104932
Try to come up with a word or expression that anyone who submitted this issue previously would have used in the description. You have a better chance of finding the previous bugs if you use terms that are as generic and simple as possible. SourceForge will not return any hits unless it finds all of the terms you enter in one of the bug summaries, and it cannot search the text of the reports directly. Consequently, a search for “audio” or “audio segment” is more likely to find something than a search for “audio segment resize problem.” Bear in mind spelling differences between the US and the rest of the English speaking world as well. SourceForge won't find reports about “bad behaviour” that were submitted by an American who spelled it “bad behavior,” and so on.
Input your search into the “Summary keyword:” box. Hit the “Browse” button.
If there were no results, go back and try other keywords until you run out of ideas, or until you get sick of wrestling with the lousy search facility at SourceForge. We appreciate your making an effort to find existing reports, but we don't expect you to waste an hour of your life trying to coax something out of that admittedly very lame search facility either.
If you did find a result, or results, read through the previous reports and see if your bug is already described. If it is not described to your satisfaction, you can add additional comments to existing reports, if appropriate.
If there is no previous work to draw on, then you should continue on to file a new report.
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 http://rosegarden.sourceforge.net/tutorial/RFE-guidelines.html 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.
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:
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
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.