![]() The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or the team lead assign it to them.Typically the users specify severities as they see fit. The severity tags aren't used much, except to distinguish enhancements from bugs.P4 - would be nice, but not critical, can ship without fixing.P3 - should/would like to fix for the next release.P2 - must fix before the release, but can make progress without fix.P1 - stop ship fix, need immediate attention.Set the priority with these guidelines:.If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER.If the fix is critical, the target will be the next milestone (like 3.1M3), otherwise it will go into the general 3.1 milestone, meaning we intend to address in this release.If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set appropriately.If the bug is a feature request, change the severity to enhancement.once a bug is validated, it goes to prioritization.the bug may be a user problem, or may be intended behavior - these get annotated with the reason/information and RESOLVED to INVALID or WONTFIX or WORKSFORME (generally, INVALID means the report is just bogus, WORKSFORME means the report is not a problem, and WONTFIX is used for things that are valid requests, but that the team can't do).the bug may get moved to another component/product. ![]() ![]() if there is no response within a week, close the bug (RESOLVED INVALID or WONTFIX) telling the submitter to re-open once they have more info.The bug remains in the NEW state until enough information is received to validate it. if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc.verify if the bug is really a bug or if it belongs to this component.At the start of each day, each project/component team lead does bug triage.Bugzilla provides a mechanism to watch another email address and developers are expected to use this to watch the component owner's address to monitor the incoming bugs for their projects/components.Users may not change the Committer owned fields - this is enforced by social convention.The Committers "own": status, resolution, and priority.Users "own": component, version, platform, OS, severity, summary, and description.The Eclipse projects have different schemes for using Bugzilla, but a common one is as follows: The Bugzilla documentation describes the basic mechanics and outlines the bug lifecycle that is designed into Bugzilla: A common question new projects ask is "how should we use Bugzilla effectively?".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |