Changes between Version 22 and Version 23 of TriagingTestFailures


Ignore:
Timestamp:
Mar 1, 2011 2:23:55 PM (10 years ago)
Author:
Adam Roben
Comment:

Moved the expected failure policy discussion link to a more appropriate place

Legend:

Unmodified
Added
Removed
Modified
  • TriagingTestFailures

    v22 v23  
    8383 * If you know why the test is failing, and know how to fix it (e.g., by making a change to WebKit or checking in new correct results), then fix it and close the bug!
    8484 * Otherwise, do one of the following and note what you did in the bug you filed, then remove the `MakingBotsRed` keyword.
    85    * If the test fails every time and the test's output is the same every time, check in new results for the test and include the bug URL in your ChangeLog. (See more discussion of this policy [http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10017 here].)
    86      * You should do this even if the test's output includes failure messages or incorrect rendering. By running the test against these "expected failure" results rather than skipping the test entirely, we can discover when new regressions are introduced.
     85   * If the test fails every time and the test's output is the same every time, check in new results for the test and include the bug URL in your ChangeLog.
     86     * You should do this even if the test's output includes failure messages or incorrect rendering. By running the test against these "expected failure" results rather than skipping the test entirely, we can discover when new regressions are introduced. (See more discussion of this policy [http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10017 here].)
    8787   * If the test fails intermittently, or crashes, or hangs, add the test to the appropriate Skipped files (e.g., `LayoutTests/platform/mac-leopard/Skipped`). Include a comment in the Skipped file with the bug URL and a brief description of how it fails, e.g.:
    8888{{{