Bug Life Cycle

Introduction

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.

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 with the latest sources on OS X or otherwise has enough information to move forward. If the bug is not reproducible with the latest sources, but appears to occur only on the platform stated in the platform field, the PlatformOnly keyword is added as well as setting the status to NEW. 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’s email 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 another internal system, such as Apple’s internal Radar system, and the person who commits the bug has access to that system, then the person who commits the bug should also change the state of the bug appropriately in the internal system. For a Radar bug the new appropriate state would be 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.2