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