ReleaseEngineering/BuildFaster/Meetings/2011-08-31: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Details =
= Details =
August 17, 2011 @ 9am PDT / 12pm EDT
August 31, 2011 @ 9am PDT / 12pm EDT


dial-in x92 304
dial-in x92 304
Line 9: Line 9:


= Agenda =
= Agenda =
* [http://brasstacks.mozilla.com/gofaster/# Dashboard site] is live and fast now (thanks to wlach); what do all the numbers mean?
* Will Lachance has made some awesome [http://brasstacks.mozilla.com/gofaster/#/buildcharts build charts] which show what's happening when for each commit.  Need to discuss findings.  Possible action items:
* related to above, where are we w.r.t our 2-hour goal?  Which open items are going to produce the greatest improvements?
** Split mochitest-browser-chrome out from mochitest-other, to bring all test chunks into the 30-min target range.  Currently mochitest-other takes 60-90 minutes on debug builds.
** Investigate what to do about long builds that are caused by full hg clones and full builds on clobbered machines.
* Review the Action Items & Bugs
* Review the Action Items & Bugs


== Action items from last time ==
== Action items from last time ==
* jgriffin to find a way to compare build turnaround time stuff.  Make something like "compare talos" where you feed it a changeset ID from try and it compares your build/test times with current data from m-c.
* {{done|will}} to follow up with catlee regarding dashboard calculations - new calculations are used in the [http://brasstacks.mozilla.com/gofaster/# GoFaster dashboard]
* wlach to file bugs on other xpcshell test slowness he found
* {{done|jgriffin}} to change test run comparison routine to compare against a range of recent m-c runs instead of one run to help mitigate the fact that test durations vary considerably per run, even when equivalent
* wlach to ask places devs if we need all places tests to hit disk
* {{done|jgriffin}} to get data on infrequently failing tests, and how long they take to run
* wlach to start digging into browser-chrome slow tests
** for mochitest-plain, 95% of tests have never failed in the past 6 months
** list of tests that [http://people.mozilla.org/~jgriffin/passing_mochitests_6mo.json haven't failed in past six months]
** list of tests that [http://people.mozilla.org/~jgriffin/failing_mochitests_6mo.json have failed in past six months]
* {{done|ted}} to file bug about harnesses downloading symbols on demand - {{bug|679759}}
* Any [https://bugzilla.mozilla.org/buglist.cgi?list_id=935439&resolution=---&status_whiteboard_type=anywordssubstr&query_format=advanced&status_whiteboard=buildfaster%3Ap2%20buildfaster%3Ap3%20buildfaster%3Ap4%20buildfaster%3Ap5 p2] bugs need to escalate?
* Any [https://bugzilla.mozilla.org/buglist.cgi?list_id=935439&resolution=---&status_whiteboard_type=anywordssubstr&query_format=advanced&status_whiteboard=buildfaster%3Ap2%20buildfaster%3Ap3%20buildfaster%3Ap4%20buildfaster%3Ap5 p2] bugs need to escalate?


Line 33: Line 37:
== Actions for next time ==
== Actions for next time ==


* will to follow up with catlee regarding dashboard calculations
* catlee to add builder name to the .csv that's being used to generate the buildcharts so we can filter out re-triggers and nightlies, etc
* jgriffin to change test run comparison routine to compare against a range of recent m-c runs instead of one run to help mitigate the fact that test durations vary considerably per run, even when equivalent
* wlach to update buildcharts to indicate job submission time, so it's easier to see wait times
* jgriffin to get data on infrequently failing tests, and how long they take to run
* catlee and jgriffin to coordinate re: gofaster session at the all-hands
* ted to file bug about harnesses downloading symbols on demand

Latest revision as of 15:21, 28 September 2011

Details

August 31, 2011 @ 9am PDT / 12pm EDT

dial-in x92 304

Backchannel #buildfaster on irc.mozilla.org

etherpad notes

Agenda

  • Will Lachance has made some awesome build charts which show what's happening when for each commit. Need to discuss findings. Possible action items:
    • Split mochitest-browser-chrome out from mochitest-other, to bring all test chunks into the 30-min target range. Currently mochitest-other takes 60-90 minutes on debug builds.
    • Investigate what to do about long builds that are caused by full hg clones and full builds on clobbered machines.
  • Review the Action Items & Bugs

Action items from last time

  • [DONE] will to follow up with catlee regarding dashboard calculations - new calculations are used in the GoFaster dashboard
  • [DONE] jgriffin to change test run comparison routine to compare against a range of recent m-c runs instead of one run to help mitigate the fact that test durations vary considerably per run, even when equivalent
  • [DONE] jgriffin to get data on infrequently failing tests, and how long they take to run
  • [DONE] ted to file bug about harnesses downloading symbols on demand - bug 679759
  • Any p2 bugs need to escalate?

Review [buildfaster:p1] bugs

Review current activities

  • we've put investigation of running debug tests with opt xpcshell on hold, since opt debug builds seem likely to materialize sometime soon (bug 669953)
  • still need a mechanism to track individual slow tests; jmaher suggested the correct metric to do this is test duration/test asserts; need to update the logparser to handle this

Review [buildfaster:?] bugs

Questions

Actions for next time

  • catlee to add builder name to the .csv that's being used to generate the buildcharts so we can filter out re-triggers and nightlies, etc
  • wlach to update buildcharts to indicate job submission time, so it's easier to see wait times
  • catlee and jgriffin to coordinate re: gofaster session at the all-hands
Retrieved from "https://wiki.mozilla.org/index.php?title=ReleaseEngineering/BuildFaster/Meetings/2011-08-31&oldid=352381"