Changes between Version 8 and Version 9 of TriagingTestFailures

Timestamp:

Nov 2, 2010, 10:00:49 AM (14 years ago)

Author:

Adam Roben

Comment:

More wordsmithing

TriagingTestFailures

@@ -53 +53 @@
 = File bugs for the failures =
 
-If multiple tests are failing for the same reason, you should group them together into a single bug. If a test fails on multiple platforms and those platforms will need separate fixes, you should file one bug for each failing platform.
+If multiple tests are failing for the same reason, you should group them together into a single bug. You should group them together into a single bug even if you aren't 100% certain they're failing for the same reason. If you're wrong, whoever investigates the failures later will figure this out and file new bugs as needed.
+
+If a test fails on multiple platforms and those platforms will need separate fixes, you should file one bug for each failing platform.
 
  1. Go to http://webkit.org/new-bug
@@ -72 +74 @@
 = Get the bots green again =
 
- * If you know what the root cause is, 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!
- * If the tests fail every time and the tests' output is the same every time, check in new results for the tests and include the bug URL in your ChangeLog.
-   * You should do this even if the test is "failing". By running the test against these "expected failure" results rather than skipping the test entirely, we can discover when new regressions are introduced.
- * If the tests fail intermittently, or crash, or hang, add the tests 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.:
+ * 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!
+ * 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.
+   * 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.
+ * 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.:
 {{{
 # Sometimes times out http://webkit.org/b/12345