8.2 The Bug Squad

To help keep track and organize all issues are a group of tireless volunteers collectively known as the Bug Squad. Composed mainly of non-programmers, the Bug Squad’s responsibilities include:

• Monitoring the LilyPond Bugs mailing list looking for any issues reported by other users ensuring that they are accurate and contain enough information for the developers to work with, preferably with (web)Tiny examples section ‘Tiny examples’ in General Information and if applicable, screenshots.
• Adding new issues to the issue tracker or updating existing issues with new information.
• Verifying issues in the issue tracker that have been marked as ‘fixed’; making sure either that the fix works or (in the case of Documentation for example) has at least been commited to the code base.

The Bug Meister also helps check the current Regression tests and highlights any significant changes (or problems) since the previous LilyPond release.

If you would like to be part of the Bug Squad, please contact the Bug Meister.

8.2.1 Bug Squad setup

We highly recommend that you configure your email client to use some kind of sorting and filtering as this will significantly reduce and simplify your workload. Suggested email folder names are mentioned below to work when sorted alphabetically.

1. Read every section of the Issues chapter in this guide.
2. Subscribe your email account to bug-lilypond. See https://lists.gnu.org/mailman/listinfo/bug-lilypond.
3. Send your email address to the Bug Meister.
4. Create your own GitLab login (required to manage issues):
   • Go to https://gitlab.com/users/sign_in.
   • Click on the ‘Register’ tab to create a new account.
   • Fill in your details as required and click the Register button to complete the registration.
5. Go to https://gitlab.com/lilypond and ‘Request access’ to the group. Additionally send your GitLab username (not your email address) to bug-lilypond@gnu.org, asking to be given appropriate permissions to manage issues.
6. Configure your email client: Any email sent To: or CC: to

   bug-lilypond

   should be configured to go into a bug-current folder.

8.2.2 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 20 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 20 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 as of July 2015

Monday: Federico Bruni
Tuesday: Graham Percival
Wednesday: Simon Albrecht
Thursday: Colin Campbell
Friday: Ralph Palmer
Saturday: Colin Campbell
Sunday: Graham Percival

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:

1. 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.
2. If the email is a question about how to use LilyPond, reply with this response:

   For questions about how to use LilyPond, please read our documentation available from: https://lilypond.org/website/manuals.html or ask the lilypond-user mailing list.

3. If the email mentions “the latest git”, or any version number that has not yet been officially released, forward it to lilypond-devel.
4. 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: https://lilypond.org/website/bug-reports.html

5. 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 responsibility to understand it.

6. 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: https://lilypond.org/website/help-us.html

7. 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)

8. 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.

Regular maintenance

After every release (both stable and unstable):

• Issues to verify: go to

  https://gitlab.com/lilypond/lilypond/-/issues?state=closed&label_name[]=Status%3A%3AFixed

  You should see a list of issues that have been marked as ’Status::Fixed’ by a developer. If the developer has done their job properly, the issue should have the “Labels” field filled in with “Fixed_x_y_z”, where X is the major version, y the minor version and z the current release.

  Fixed_2_19_39

  This will help you work out which you can verify - do not verify any issues where the claimed fixed build is not yet released. Work your way through these as follows:

  If the issue refers to a bug, try to reproduce the bug with the latest officially released version (not one you’ve built yourself from source); if the bug is no longer there, mark the issue “Status::Verified” (i.e., “the fix has been verified to work”).

  Quite a few of these will be issues tracking patches. You do not have to prove these patches work - simply that they have been pushed into the code base. The developer should have put information similar to “Pushed as as d8fce1e1ea2aca1a82e25e47805aef0f70f511b9” in the tracker. The long list of letters and numbers is called the “committish”. Providing you can find this at the git tracker:

  http://git.savannah.gnu.org/gitweb/?p=lilypond.git

  then you should mark the issue as verified. A quick way of finding these is to enter the committish at the following address:

  http://philholmes.net/lilypond/git/

  The Issue tracker also requires that any issues labelled as “Duplicate” are also verified. Check that the linked issue is a duplicate and verify the issue.

  A few (approximately 10%) of the 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.

• The official regression test comparison is online at:

  https://lilypond.org/test/

  If anything has changed suspiciously, ask if it was deliberate. If the text output from LilyPond (the logfile) changes, the differences will be displayed with a + before text added to the logfile and - before any text removed from the logfile. This may or may not be suspicious.

  More information is available from in Precompiled regression tests.

• Check for any incorrectly-classified items in the tracker. This generally just means looking at the grid to see any items without a Type.

This document was generated by gub on July 13, 2020 using texi2html 1.82.