haslotus.blogg.se - Mozilla thunderbird review

Rubber-Stamp Approvals for Intermittently Failing ("Orange") Test Fixes/Debugging These bugs should have the in-testsuite- flag set.

Certain build-config or tooling bugs which don't affect the actual product cannot be usefully tested.

The in-testsuite? flag should be set on the bug until the framework has been completed and the test code is running automatically. A bug should be filed on the needed test framework.

If an automated test framework is needed but is not yet available, the developer is encouraged to write appropriate test code and commit it.

Unit tests must be included in patches and reviewed just like any other code.

Once unit tests are committed, the in-testsuite+ flag should be set on the bug.

Patches are required to include automated tests which are run during make check or via MozMill in Thunderbird, but submitters are encouraged to request exceptions from reviewers in cases where the cost is believed to outweigh the benefit.

See the full super-review policy for more details.

Super-review is required in certain situations: significant architectural refactoring, any change to any API, all changes that affect how code modules interact.

If a reviewer feels that the patch would benefit from additional reviews, they should request a second review from an appropriate person.

Sub-module peers may only grant review in the listed sub-module.Peers may grant review in any area covered by mailnews/, provided they feel confident in their knowledge of the code being changed.Wherever possible, significant patches in a certain area should be reviewed by one of the listed sub-module owner/reviewers.Rules for all patches affecting mailnews/ and mail/ Mike Conley (:mconley) can also provide useful feedback, but Blake is the current ultimate decider for UI choices in Thunderbird. To obtained a ui-review on an attachment, set ui-review to '?' and enter :bwinton (for Blake Winton) as the requestee.All patches that affect user experience or interfaces on Thunderbird should have ui-review on those patches in addition to the reviews required below.

Getting early ui-reviews this reduces the chance that work is rejected due to needing further user experience changes, and hence is aimed at saving time for the developer and reviewers. Note: It is recommended that when working on bugs that affect user experience or interfaces, that ui-review is obtained at an early stage in the patch development process.