STATUS RESOLUTION
The status field indicates the general health of a bug. Only certain status transitions are allowed. The resolution field indicates what happened to this bug.
UNCONFIRMED
This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "can-confirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED.
NEW
This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.
ASSIGNED
This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.
REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. No resolution yet. All bugs which are in one of these "open" states have the resolution set to blank. All other bugs will be marked with one of the following resolutions.
RESOLVED
A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED.
CLOSED
The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. FIXED
A fix for this bug is checked into the tree and tested.
INVALID
The problem described is not a bug
WONT FIX
The problem described is a bug which will never be fixed.
LATER
The problem described is a bug which will not be fixed in this version of the product.
REMIND
The problem described is a bug which will probably not be fixed in this version of the product, but might still be.
DUPLICATE
The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field.
WORKSFORME
All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the bug, for now, file it.
This document describes the life cycle of a bug in the WebKit open-source project. In most ways this is the same as the life cycle of a bug in any Bugzilla project. The Bugzilla site also includes more details about the life cycle of Bugzilla bugs.
Joost de Valk (AlthA on the #webkit IRC channel) has volunteered to answer questions about the WebKit bug life cycle. You can reach him on IRC or via email at webkit at joostdevalk dot nl.
Fresh, Unconfirmed Bugs
A freshly-created bug starts out in state UNCONFIRMED. Often it is in component New Bugs, but some bugs will be given an initial component in the initial bug-reporting step.
Confirming Bugs
The next step is for someone with Bugzilla canConfirm privileges to review the unconfirmed bug and decide whether it has enough useful information to move forward. The possible changes to the bug at this step include the following:
Resolution changed to DUPLICATE if the bug is determined to have the same cause as a bug reported earlier.
Resolution changed to WORKSFORME if the bug seems to not be present in the latest sources.
Resolution changed to INVALID if the bug does not describe a problem with WebKit.
Resolution changed to WONTFIX in the rare case that the bug seems valid but there's a specific reason why it should not be fixed in WebKit (usually this would be a cross-browser compatibility issue).
Comments/questions added if the bug does not have enough information to move forward.
Status changed to NEW if the bug is reproducible or otherwise has enough information to move forward. Along with changing the status, the component should also be set to an appropriate one more specific than New Bugs if necessary.
Analyzing Bugs
Each bug is initially assigned to the person designated as owner of the component. The assignee should move the bug from status NEW to status ASSIGNED after they have read the bug and are satisfied that it represents a real problem in WebKit. If they are not satisfied about this, they should perform one of the actions mentioned in the Confirming Bugs section above. The same procedure is followed for bugs with status REOPENED (see Verifying Fixes below).
The assignee represents the person who is expected to take the next step in investigating or fixing a bug. If someone other than the assignee is investigating or fixing a bug, the assignee should be changed to the person doing the work. This helps prevent duplicated work. It's always helpful to add a comment explaining why an assignee has been changed.
Proposing Fixes
A proposed patch should be added as a new attachment. The attachment should have the patch checkbox checked, and the review flag set to ?. This marks the patch as awaiting review. If the patch requires the specialized knowledge of a particular reviewer, the submitter or another reviewer should put the requested reviewer'semail address in the Requestee field. Otherwise this field should be left empty. The state is left at ASSIGNED at this point; it isn't changed to FIXED until a fix has been checked into the source tree.
When the review flag's state is changed, or when a comment is made in the Edit form for an attachment, email is automatically sent to the webkit-reviews mailing list. The reviewers all subscribe to this list, and anyone else is free to do so as well.
If the submitter of a patch changes their mind about wanting a review, they should clear the review flag by choosing the blank choice in the review pop-menu.
More details about how to prepare code changes can be found elsewhere on this site.
Reviewing Proposed Fixes
A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the review flag to +. For clarity, it's helpful for the reviewer to add a comment when approving a patch. Often this comment is just "r=me", which is simply shorthand for "I have reviewed this patch and it's ready to commit".
A patch might not be ready to commit for various reasons. The bug fix might be incorrect. The test cases included in the patch might be insufficient. The bug fix and test cases might be fine but the coding style might be incorrect. The reviewer should always explain in detail why a patch is not ready to commit, so the submitter or someone else can revise the patch.
When a submitter proposes an updated patch, they should check the obsolete checkbox on the previous version of the patch. This causes it to appear crossed-out in the list of attachments on the bug's main page. At the same time as marking the old patch obsolete, the submitter should also clear the review flag. This would happen automatically in a perfect world, but doesn't currently in this one.
Committing Patches
After a patch has been approved, someone with commit privileges in the WebKit source repository will commit the patch into the source code repository. The committer should change the state of the bug to FIXED; generally the assignee is left unchanged at this point.
All of the people with commit privileges should be subscribed to the webkit-reviews mailing list, and so they will receive email when a patch is approved and thus ready to be committed. If an approved patch has not been committed for what seems to be an inordinately long time, the patch submitter could send email requesting status to this mailing list. As a last resort, the patch submitter could contact the reviewer directly. Due to everyone's busy schedules, some delays in getting patches reviewed, and then in getting them committed, are inevitable.
If the bug report mentions that the same bug is represented in Apple's internal Radar system, and the person who commits the bug has acces to Radar, then the person who commits the bug should also set the state of the Radar bug to Software Changed/Integrate.
Verifying Fixes
After the patch for a bug has been committed, the fix still needs to be verified. Typically this step is done by the person who originally submitted the bug report. If the submitter is not available or does not feel that they can verify the fix, the verification step can be done by anyone with bug editing privileges who is familiar enough with the originally reported problem to be confident about testing it. Note that once a bug is in the FIXED state, the assignee can no longer be changed. This means that a bug that needs to be verified will not usually be assigned to the person expected to verify the bug.
To verify a bug fix, build and run the sources that include the fix, and check whether the originally reported problem still occurs. If the problem no longer occurs, change the resolution to VERIFIED. If the problem does still occur, change the resolution to REOPENED and assign it to the person who submitted the patch.
Closing Bugs
Fixed bugs have the VERIFIED resolution until a version of WebKit that includes the fix has been publicly released. At this point, the resolution is changed to CLOSED.
|
