introduce

This article describes the lifecycle of bugs in WebKit open source projects. In most cases, this is the same lifecycle as any bug in a Bugzilla project. The Bugzilla website also includes more detailed information about Bugzilla.

New – Unconfirmed Bug

A new Bug starts in an unacknowledged state, usually in a component, but in the initial Bug report, some bugs are assigned to a component.

Confirm the Bug

The next step is for people with Bug confirmation authority to Review the unconfirmed bugs and decide whether to move forward.

  • If it is determined that the error has the same cause as the previously reported error, change the solution to DUPLICATE.

  • If the bug does not appear to exist in the latest source code, change the solution to WORKSFORME.

  • If the error does not describe a WebKit problem, the resolution is changed to INVALID.

  • In rare cases, change the solution to WONTFIX, but point to a specific reason (usually this will be a cross-browser compatibility issue).

  • If the error does not have enough information to continue, add Comments/questions.

  • If the bug is replicable in the latest source code on OSX, or there is enough information to move forward, the status changes to “New.” If the bug is not replicable in the latest source, but seems to occur only on the platform declared in the PlatformOnly field, add the PlatformOnly keyword and set the state to NEW. Along with changing the state, you should also set the component to be more specific than the new bug, if necessary.

Analysis of the Bug

Each bug is initially assigned to the person designated as the component owner. The assignee should change the bug status from NEW to ASSIGNED after reading the bug and being convinced that it represents a real problem in WebKit. If they are not happy with this, they should perform one of the actions “confirm the Bug” above. For a Bug with a state of “REOPEN”, follow the same process (see verification fixes below).

The appointee represents the person who is expected to take the next step to investigate or fix the error. If an error is being investigated or fixed by someone other than the dispatcher, the dispatcher should be changed to the person performing the work. This helps prevent duplication of effort. Is it always helpful to add a comment explaining why you want to change the grantee

Propose solutions

The proposed patch should be added as a new attachment. Attachments should check the patches check box and set the Review flag to? . This marks the patch for review. If the patch requires the expertise of a particular reviewer, the submitter or other reviewer should put the email address of the requested reviewer in the Requestee field. Otherwise, this field should be left blank. The status remains ASSIGNED. It does not change to “FIXED” until the fix is checked into the source tree.

Email is automatically sent to the WebKit Reviews mailing list when the status of the review flag changes or when a comment is made in the attached edit form. Commenters subscribe to the list, and others can do the same.

Review the repair

The reviewer will read through each proposed patch. If the patch is ready to be submitted, the reviewer changes the review flag to +. For clarity, it is helpful for reviewers to add comments when approving fixes. Usually this comment is just “r=me”, which is simply shorthand for “I’ve checked the patch and it’s ready to commit”.

For a variety of reasons, a patch may not be committed. Bug fixes may not be correct. The patches may contain insufficient test cases. Bug fixes and test cases may be fine, but the coding style may not be correct. Reviewers should always explain in detail why a patch is not ready for delivery so that the submitter or others can modify the patch.

When submitters propose a newer patch, they should check the outdated check box on the previous patch. This causes it to be crossed off the attachment list on the bug home page. The submitter should also clear the Review flag when marking the old patch as obsolete. In a perfect world, that would happen automatically, but it hasn’t.

Submit patches

After a patch is approved, the person with submission permission in the WebKit source repository submits the patch to the source repository. The submitter should change the status of the bug to FIXED; Normally, the transferee stays the same on this point.

All people with submission permission should subscribe to the WebKit Reviews mailing list so they will receive an email when patches are approved and ready to be submitted. If it seems too long before an approved patch has been submitted, the patch submitter can email the request status to this mailing list. As a last resort, patch submitters can contact the reviewer directly. With everyone’s busy schedules, some delay in viewing patches and submitting patches is inevitable.

If the bug report mentions that the same bug is present in another internal system, such as Apple’s internal radar system, and the person who submitted the bug has access to that system, then the person who submitted the bug should also change the status of the bug appropriately in the internal system. For radar errors, the new appropriate status would be software changes/integrations.

Validation patch

After submitting a patch for a bug, you still need to validate the fix. Usually this step is done by the person who originally submitted the bug report. If the submitter is not available or does not feel they can verify the fix, the verification step can be done by anyone with bug editing permission who is familiar enough with the problem initially reported to be confident enough to test it. Note that once a bug is in a FIXED state, the assignee cannot be changed. This means that bugs that need to be verified are usually not assigned to people who expect them to be verified.

To verify a bug fix, build and run the source code that contains the fix and check to see if the problem originally reported still appears. If the problem does not recur, change the solution to VERIFIED. If the issue still exists, please rename the solution to Childrens and assign it to the people who have submitted fixes.

Close the Bug

FIXED bugs are verified until a WebKit version containing the fix is released publicly. At this point, the solution is CLOSED;

Ps: assault stand delete