Layout Tests Task Force syncup 11/16/2009
- Number of failing tests: 635
- dashboard: http://chromiumlttf.appspot.com/
- bunch of rebaseline fixes coming up
- last week was not as productive because mstone 4.0 bugs were being
worked on
- we can see that new failures accumulated last week because of this
- this is a sign of sustainability issues we should think about
- overarching goal of LTTF is maintaining compatibility
- compatibility with Safari Mac
- compatibility w/ the web
- have we been spending too much time on test harness, rebaselines,
etc?
- sustainability
- how do we make this a non-infinite-length task force?
- we should start brainstorming about sustainability
- some ideas:
- assign different priorities to different tests
- we will start a Wave to discuss...
-
https://wave.google.com/a/google.com/?AuthEventSource=SSO#minimized:nav,minimized:contact,minimized:search,restored:wave:google.com!w%252B-7O-i99aC
OKR status:
- Fix all Windows layout tests: make test_expectations.txt only contain
items that we will never fix, features we have not yet implemented, or bugs
less than one week old that are a result of a recent WebKit merge.
- see sustainability issues discussed above
- All LTTF bugs that we fix are fixed across all three platforms (Win,
Mac, Linux), unless they depend on features not yet implemented.
- seem to be doing well on this
- Fix any crashing layout tests within a week of occurrence.
- doing okay, people tend to jump in fairly quickly
- Work with the green tree task force to eliminate flakiness of layout
tests.
- could we run tests twice to hide/avoid the flakiness?
- people often wait for it to run again anyway
- this could be very useful
- number of flaky tests is probably going to go up before they go down
- Set up a public dashboard which tracks the number of failing layout
tests over time on the Chromium site.
- done
--
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
