In an effort to provide more transparency into what the team is working on, I'm sending out the meeting notes from the green tree task force to chromium-dev, below. I will try to send further notes to chromium-dev from our meetings.
We looked at the OKRs we signed up for as a taskforce and tried to track where we were status-wise. Nicolas put together an awesome doc for this, which you can find at http://docs.google.com/Doc?id=dc2xdcr4_0ckd542gk In a nutshell: - Tree closures - tree is staying closed for about the same amount of time as it was before we started the taskforce. - biggest area of opportunity is in more sheriff training and aggressive sheriffing activities - expect more sheriff duty documentation and a PSA - Tooling - "drover," a tool written by laforge@ is awesome. Makes it really easy to revert changes - Will be pushing sheriffs to use drover ruthlessly - Flakiness - Brought down to acceptable levels for unit tests. Need help to keep it that way and not regress. - Really bad for WebKit, especially mac and linux. *Need Help.* See linked doc for specific bug numbers. - Build times - Most slaves below 30m, still room for improvement - Focused on fixing the non-memory tests, bugs linked in doc but would love help to make tests take less time. - Work on make and shared object build should help across the board Who's doing what: - Bevc doing buildbot and resource changes as necessary to turn up more bots - ojan looking at making layout test dashboard work for more than just layout tests (e.g. to also cover unit tests) so that you can see a test's history - mmoss working on getting make build up & running and shared object build, should reduce base cycle time - thestig working on distcc build - dkegel: looking at better sharding valgrind, and potentially trying to get valgrind to work for windows build as well - nsylvain: sharding bots, adding bots as necessary (just added a bunch for chromeos), making reactive fixes, and looking at infrastructure changes for buildbot hosting Notes from individuals: Andrew Scherkus notes that: I've been having success rebasing/fixing media layout tests but intentionally marking them as flaky in test_expectations.txt. I then monitor the flakiness dashboard and download any failures using Glenn's seriously amazing test formatter tool. The idea is to never trust a local pass and instead only rely on the flakiness dashboard. It inflates test_expectations.txt in the short term, but keeps the tree green while collecting flakiness data. If everything looks good for about a day or two, I remove the entry from test_expectations.txt Ojan notes that: When tests time out we now keep the results in the layout_test_results.zip file. So there's a concrete path toward addressing timeout flakiness, which is by far the most prominent. Please help out! Also, we need a volunteer to work on printing out stack traces when webkit tests crash. That would help considerably with crashing flakiness. Due to disk constraints, maintaining full dumps is difficult. Any takers for either one? (ping me privately) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
