HomeHow-tosSoftware Development, Bugs, Wishlists, LaunchpadReporting Bugs on Launchpad

1.2. Reporting Bugs on Launchpad

Reporting Bugs on Launchpad

If you would like to report a bug or wishlist item for the Evergreen software, please do so on  the Launchpad bugs site.

You can also "Add Heat" to a bug there.  

When reporting a bug, please include as much information as you can:

  • The version of Evergreen that you are using.
  • The version of the PostgreSQL database server that you are using (if known).
  • The version and flavor/distribution of the operating system that hosts your Evergreen installation (if known).
  • The version of OpenSRF that you use with Evergreen (if known).
  • What steps you took that trigger the bug.
  • What happened.
  • What you expected to happen.

Frequently, users have questions regarding the different statuses and importance values assigned to bugs on Launchpad. This page provides general definitions for the various attributes that bugs get assigned as they move throughout their lifecycle.

Bug Status Definitions

  • New - The default status. This defines a "new" bug that has not yet been claimed to be fixed.
  • Incomplete - The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information.
  • Opinion - The bug report expresses an opinion and is not actually a bug in the software.
  • Invalid - Bug is unreproducible by multiple users, other than the submitter.
  • Won't Fix - Bug will not be fixed. Reasons may vary.
  • Confirmed - Bug is confirmed by one or more users, other than the submitter. Bug wrangler team members should assign an importance, if not already set.
  • Triaged - Bug has been acknowledged. It isn't new or confirmed, but we'll assign a real status later.
  • In Progress - A developer is actively working on a solution to this bug, or may be awaiting commit/release.
  • Fix Committed - A fix for this bug has been committed to one or more release versions and is awaiting release.
  • Fix Released - A fix for this bug has been officially released to the public.

Bug Importance Definitions

  • Critical - Showstopper: breaks build, destroys data.
  • High - Must be fixed by release.
  • Medium - Normal Severity
  • Low - Not very important.
  • Wishlist - Feature requests, development ideas/proposals
  • Undecided - The default status. This bug is awaiting proper importance and status values.


Assignments are used to show who is currently looking at a bug, either writing code or looking over code to be merged into the main code base. It is a convenience so that other developers know that someone else is still busy with some work on the code.


NOTE: The following examples are based on the 2 series of Evergreen and use 2.7 terminology to give some substance to how milestones may operate.

Milestones for wishlist bugs for new features may be assigned to the next release for future review before they are fully finished. For example, assigning a new feature bug to "2.next" may be appropriate if you expect that code may be ready by the time of the initial review process. This is intended for developers/contributors to show their plans ahead of time and work towards completion of those bugs prior to the start of the review process. As new milestones are added for the 2.7 series, bugs may shift milestone targets depending on how much work developers add to their bug tickets. So a bug might start with a target of "2.next", go to a more specific target of "2.7.0-alpha1", but slip in the timeline and get a final resting milestone of "2.7.0-beta1".

Bug reports and fixes may be assigned to the actual milestone where we plan to include the fix. These normally only get specific milestones now when there is working code to test and there is a "pullrequest" tag applied to the bug ticket. Occasionally, we may also add specific milestones where we intend to apply a bug ticket as a "blocker" against the release of that particular milestone, but this is reserved for only the most severe bugs.


Look for the "Tags" block on the right sidebar of the main bugs list on Launchpad. The counts only include bugs in an "open" status (excluding things like "Fix Released", "Invalid" and "Won't Fix"). You can click on a tag to search for all bugs with that tag. If you want more complex search features, go to the Advanced Search and look for the "Tags" section near the bottom.

There are a few tags that we use in a special way:

  • pullrequest: Added when code that is believed to work has been posted to the bug. If that code is proven to have problems, this tag is removed and usually replaced with "needsrepatch".
  • needsrepatch: Added when code has been posted but needs work before it will be ready to review or test.
  • signedoff: Added when code has been tested and approved (by adding a Git "signed-off-by" line, or by posting the equivalent in a comment).
  • needstest: Added when code probably needs an automated test included.
  • needsreleasenote: Added when code needs a release note included.
  • bitesize: Added to bugs that someone new to Evergreen development should be able to fix.

This information is from the Evergreen DokuWiki.

Link here


© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.

Knowledge Tags

This page was: Helpful | Not Helpful