[ << Issues ]	[Top][Contents][Index][ ? ]			[ Regression tests >> ]
[ < Bug Squad checklists ]		[  Up : Issues ]	[ Adding issues to the tracker > ]

8.5 Issue classification

The Bug Squad should classify issues according to the guidelines given by developers. Every issue should have a Status and Type; the other fields are optional.

Status (mandatory)

Open issues:

• New: the item was added by a non-member, despite numerous warnings not to do this. Should be reviewed by a member of the Bug Squad.
• Accepted: the Bug Squad added it, or reviewed the item.
• Started: a contributor is working on a fix. Owner should change to be this contributor.

Closed issues:

• Invalid: issue should not have been added in the current state.
• Duplicate: issue already exists in the tracker.
• Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor.
• Verified: Bug Squad has confirmed that the issue is closed. This means that nobody should ever need look at the report again – if there is any information in the issue that should be kept, open a new issue for that info.

Owner (optional)

Newly-added issues should have no owner. When a contributor indicates that he has Started or Fixed an item, he should become the owner.

Type (mandatory)

The issue’s Type should be the first relevant item in this list.

• Type-Critical: normally a regression against the current stable version or the previous stable version. Alternatively, a regression against a fix developed for the current version. This does not apply where the “regression” occurred because a feature was removed deliberately - this is not a bug.

  Currently, only Critical items will block a stable release.

• Type-Maintainability: hinders future development.
• Type-Crash: any input which produces a crash.
• Type-Ugly: overlapping or other ugly notation in graphical output.
• Type-Defect: a problem in the core program. (the lilypond binary, scm files, fonts, etc).
• Type-Documentation: inaccurate, missing, confusing, or desired additional info. Must be fixable by editing a texinfo, ly, or scm file.
• Type-Build: problem or desired features in the build system. This includes the makefiles, stepmake, python scripts, and GUB.
• Type-Scripts: problem or desired feature in the non-build-system scripts. Mostly used for convert-ly, lilypond-book, etc.
• Type-Enhancement: a feature request for the core program. The distinction between enhancement and defect isn’t extremely clear; when in doubt, mark it as enhancement.
• Type-Patch: tracking a patch on Rietveld. Bug squad should not need to use this label.
• Type-Other: anything else.

Opsys (optional)

Issues that only affect specific operating systems.

Patch label (optional)

Normal Bug Squad members should not add or modify Patch issues except to verify them; for all other Patch work, leave them to the Patch Meister.

• Patch-new: the patch has not been checked for “obvious” mistakes. When in doubt, use this tag.
• Patch-review: the patch has no “obvious” mistakes (as checked by the Patch Meister), and is ready for review from main developers.

  Developers with git push ability can use this category, skipping over patch-new.

• Patch-needs_work: a developer has some concerns about the patch. This does not necessarily mean that the patch must be changed; in some cases, the developer’s concerns can be resolved simply by discussion the situation or providing notation examples.

  If the patch is updated, the category should be changed to patch-new (for normal contributors) or patch-review (for developers who are very confident about their patch).

• Patch-countdown: final call for any patch problems
• Patch-push: patch has passed the countdown and should be pushed.
• Patch-abandoned: the author has not responded to review comments for a few months.

Other items (optional)

Other labels:

• Regression: it used to work intentionally in the current stable release or the previous stable release. If the earlier output was accidental (i.e. we didn’t try to stop a collision, but it just so happened that two grobs didn’t collide), then breaking it does not count as a regression.

  To help decide whether the change is a regression, please adopt the following process:

  1. Are you certain the change is OK? If so, do nothing.
  2. Are you certain that the change is bad? Add it to the tracker as a regression.
  3. If you’re not certain either way, add it to the tracker as a regression but be aware that it may be recategorised or marked invalid.

  In particular, anything that breaks a regression test is a regression.

• Frog: the fix is believed to be suitable for a new contributor (does not require a great deal of knowledge about LilyPond). The issue should also have an estimated time in a comment.
• Bounty: somebody is willing to pay for the fix. Only add this tag if somebody has offered an exact figure in US dollars or euros.
• Warning: graphical output is fine, but lilypond prints a false/misleading warning message. Alternately, a warning should be printed (such as a bar line error), but was not. Also applies to warnings when compiling the source code or generating documentation.
• Security: security risk.
• Performance: performance issue.

If you particularly want to add a label not in the list, go ahead, but this is not recommended, except when an issue is marked as fixed. In this case it should be labeled Fixed_mm_MM_ss, where mm is major version, MM minor version and ss current release.

---

[ << Issues ]	[Top][Contents][Index][ ? ]			[ Regression tests >> ]
[ < Bug Squad checklists ]		[  Up : Issues ]	[ Adding issues to the tracker > ]

<< Back to Documentation Index

LilyPond — Contributor’s Guide