The purpose of this page is to:

• Help detect new test failures, that is test / Wine regressions.
• Help diagnose failures by showing when they are specific to a set of Windows versions, a locale, a day of the week, etc.
• Help detect test configuration changes that increase the number of failed test units.
• Help identify test configurations that get worse results than their peers.

The patterns on this page read as follows:

• Each line corresponds to a test configuration sorted by platform and tag name.
• Test configurations with no failure for a given test are omitted from that test's pattern.
• Each column corresponds to a WineTest build from oldest to newest.
• Lines with a _N suffix are when WineTest was run more than once for a test configuration + build combination. They are rare and thus hang at the bottom of the pattern to not disrupt it.
• Each cell is a single letter describing the result for that test. See the tooltips for a description. Click on the letter to go to that result page.
• Each result is also color coded to make the patterns pop out. There is one color per type of result (crash , timeout, etc.), and one per number of failures (to help detect changes).
• Failure modes that have not been seen before (test that newly crashes, new failure count, etc.) are highlighted, as well as the configuration names in which they appear.
• Below the patterns is a line showing which builds have potentially related commits if any.
• Bugs related to a test are shown above the pattern. New (and recently modified) bugs are highlighted. Slightly older bugs are also highlighted as a reminder to investigate them while the pattern may still contain traces of their inception.
• Related bugs should have the source and testcase keywords, and their description should contain module:unit, module/unit or module/tests/unit.

The patterns are grouped according to the likelihood that they contain new failures:

• 53 tests recently started failing (the 10 oldest builds had no failure).
• 14 tests failed in new ways in the 10 most recent builds (for instance they have more failures than before).
• 117 tests have failures... as usual :-(.
• 222 tests look like they are fixed: they had no failure in the most recent 10 builds but that may also just be a lucky streak.
• 9 tests have related bugs but no failure whatsoever. Maybe the bugs can be closed.
• 36 tests have no failures but have potential memory bugs (leaks, overflow, uninitialized data, etc). These may be out of date or may cause failures later on.

Unlike the other patterns on this page, the one below shows the number of failed test units for each configuration.