[ << Issues ] | [Top][Contents][Index][ ? ] | [ Regression tests >> ] | ||
[ < Bug Squad setup ] | [ Up : Issues ] | [ Issue classification > ] |
7.3 Bug Squad checklists
When you do Bug Squad work, start at the top of this page and work your way down. Stop when you’ve done 15 minutes.
Please use the email sorting described in Bug Squad setup.
This means that (as Bug Squad members) you will only ever respond
to emails sent or CC’d to the bug-lilypond
mailing list.
Emails to you personally
You are not expected to work on Bug Squad matters outside of your
15 minutes, but sometimes a confused user will send a bug report
(or an update to a report) to you personally. If that happens,
please forward such emails to the bug-lilypond
list so that
the currently-active Bug Squad member(s) can handle the message.
Daily schedule
Sunday: Valentin Monday: Dmytro Tuesday: James Bailey Wednesday: Ralph Thursday: Phil Holmes Friday: Urs Liska, Patrick Saturday: Kieren
Emails to bug-answers
Some of these emails will be comments on issues that you added to the tracker.
- If they are asking for more information, give the additional information.
- If the email says that the issue was classified in some other manner, read the rationale given and take that into account for the next issue you add.
-
Otherwise, move them to your
bug-ignore
folder.
Some of these emails will be discussions about Bug Squad work; read those.
Emails to bug-current
Dealing with these emails is your main task. Your job is to get rid of these emails in the first method which is applicable:
- If the email has already been handled by a Bug Squad member (i.e. check to see who else has replied to it), delete it.
-
If the email is a question about how to use LilyPond, reply with
this reponse:
For questions about how to use LilyPond, please read our documentation available from: http://lilypond.org/website/manuals.html or ask the lilypond-user mailing list.
-
If a bug report is not in the form of a Tiny example, direct the
user to resubmit the report with this response:
I'm sorry, but due to our limited resources for handling bugs, we can only accept reports in the form of Tiny examples. Please see step 2 in our bug reporting guidelines: http://lilypond.org/website/bug-reports.html
-
If anything is unclear, ask the user for more information.
How does the graphical output differ from what the user expected? What version of lilypond was used (if not given) and operating system (if this is a suspected cause of the problem)? In short, if you cannot understand what the problem is, ask the user to explain more. It is the user’s responsibility to explain the problem, not your reponsibility to understand it.
-
If the behavior is expected, the user should be told to read the
documentation:
I believe that this is the expected behaviour -- please read our documentation about this topic. If you think that it really is a mistake, please explain in more detail. If you think that the docs are unclear, please suggest an improvement as described by “Simple tasks -- Documentation” on: http://lilypond.org/website/help-us.html
-
If the issue already exists in the tracker, send an email to that
effect:
This issue has already been reported; you can follow the discussion and be notified about fixes here:
(copy+paste the google code issue URL)
- Accept the report as described in Adding issues to the tracker.
All emails should be CC’d to the bug-lilypond
list so that
other Bug Squad members know that you have processed the email.
Note: There is no option for “ignore the bug report” – if you cannot find a reason to reject the report, you must accept it.
Regular maintenance
After every release (both stable and unstable):
-
Regression test comparison: if anything has changed suspiciously,
ask if it was deliberate. The official comparison is online, at:
http://lilypond.org/test/
More information is available from in Precompiled regression tests.
-
Issues to verify: try to reproduce the bug with the latest
version; if you cannot reproduce the bug, mark the item
“Verified” (i.e. “the fix has been verified to work”).
http://code.google.com/p/lilypond/issues/list?can=7
A few (approximately 10%) of these fixed issues relate to the build system or fundamental architecture changes; there is no way for you to verify these. Leave those issues alone; somebody else will handle them.
[ << Issues ] | [Top][Contents][Index][ ? ] | [ Regression tests >> ] | ||
[ < Bug Squad setup ] | [ Up : Issues ] | [ Issue classification > ] |