User Tools

Site Tools


dev:bug_wrangler:faq

Evergreen Bug Wrangler FAQ

Reporting Bugs on Launchpad

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 tags 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

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.

Milestones

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.

dev/bug_wrangler/faq.txt · Last modified: 2014/05/02 09:37 by bshum

© 2008-2014 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.