Bug reports
Step 1: Known bugs
If you have input that results in a crash or an erroneous output, then that is a bug. There is a list of current bugs on our google bug tracker,
http://code.google.com/p/lilypond/issues/list
Note: Please DO NOT add bug reports directly to the bug tracker. Once an issue has been added to the tracker, feel free to add more information to that report.
Step 2: Creating a bug report
If you have discovered a bug which is not listed, please help us by creating a bug report.
Note: We only accept bug reports in the form of Tiny examples. We have very limited resources to deal with bug reports, so any non-minimal example will be rejected. Almost every bug can be demonstrated in four notes or less!
Here is an example of a good bug report:
%% the octavation command doesn't
%% change the output at all!
\version "2.10.0"
\relative c''' {
c1
#(set-octavation 1)
c1
}
Step 3: Sending a bug report
Once you have verified that the issue is not already known and created a bug report, please send it to us!
- If you are subscribed to the bug-lilypond@gnu.org mailing list, send an email like normal.
-
If you are not subscribed, you can still post a bug report with
the
gmane lilypond.bugs web interface.
However, there is a strict “no top-posting” check on the gmane interface, which is often incorrectly triggered by lilypond files. To avoid this, please add:
> I'm not top posting.
(you must include the
>) to the top of your bug report.
Once your bug has been sent to the list, our Bug Squad will examine the report. Please allow up to 24 hours, as we have a limited number of volunteers for this task. They may ask you for more information, or may add the report to the tracker and let you know what the issue number is.
You may mark the bug so that you automatically receive emails when any activity on the bug occurs. This requires you have a google account.
他の言語: deutsch, español, français, magyar, italiano, nederlands