Evergreen Bug Wrangler FAQ

If you would like to report a public bug for Evergreen, please do so on our Launchpad bugs site.

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.

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

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

When you have finished either writing or reviewing the code, please remove your assignment from a bug. If you were reviewing code and you have questions for the programmer, you may reassign the bug to them as a signal that the code still needs work. If you do this, you should also add a comment to the bug explaining why you think the code needs more work or asking your questions.

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.

A list of tag definitions in use as of 2020 can be seen here.

Use the UI Checklist for Accessibility to identify potential accessibility problems. Accessibility problems can often be spotted by just looking for things that seem glitchy or odd to you. If you have a few minutes, a keyboard, or an accessibility testing browser extension, you could help spot even more! Some tips and details on some optional tools are available on the Evergreen wiki under Accessibility Testing. The details on the top half of the Accessibility Testing page can be used in conjunction with this list.