ReleaseEngineering/BuildFaster/Meetings/2011-08-03

From MozillaWiki
Jump to: navigation, search

Details

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

Mountain View room GIGO dial-in x92 95272 (vidyo)

Backchannel #buildfaster on irc.mozilla.org

etherpad notes

Agenda

  • Desperately need live data sets for the dashboard, what's the ETA on that?
  • Taking the information public - as we make the wins, we should announce them. This is going to be a series of little wins over a long course of work. What's the best way? Blogs + newsgroup posts?
  • Review the Action Items & Bugs

Action items from last time

  • bug 670229 - follow up for individual tests that are slow - jgriffin
  • bug 673198 - follow up on tracemalloc question - ted
  • Any p2 bugs need to escalate?

Review [buildfaster:p1] bugs

  • Dashboard
    • waiting on catlee to get live data
  • Bug 670229 - jgriffin has been doing that, helping the developers run different changes against try. Slow going,
  • tracemalloc - ted needs to review the numebrs, will work with jgriffin on it.
  • Packed JS bug - pushed to try - going to get numbers today. Should have patch in review today.
  • bug 561754 - ateam work, set up the server for uploading the crash dumps to. Releng needs to fix the buildbot scripts to upload the data. We need catlee's input on this.
  • bug 623617 - set up container make files, traverse several directories, starting to get into platform directories, and going to ignore them at the moment. Generating some stats for the derecursified builds to compare with recursive builds. Working to get elapsed time per directory to figure out where we are spending our time.
  • bug 658313 PGO builds - no update
  • bug 659328 Merge talos suites - no update
  • bug 669930 - Dashboard - bug covered above
  • bug 673001 - TBPL change to display command line - we should just do it. It'd be useful to many people and new contributors.
  • bug 617503 - Slow XPCShell tests - (wlach) - Investigating why xpcshell is so slow on windows. Currently xpcshell system itself isn't that slow - they are about 33% slower on the win7 build slave compared to a modern thinkpad laptop. Looking into specific tests that are quite slow on windows compared to linux. Filed bugs for each of those issues: geolocation test, there's a test that launches 1000 processes - does it really need 1000 process tests? The places tests and addon install tests are really slow. The places tests seem to be slow when inserting into the places database. Filed bugs, raised the issue with the places guys. The test code is using the places code in a synchronous manner, which is probably correct for a unit test, but still doesn't explain why it should be *that* slow. It shouldn't take 100ms to flush a 100K change to the database.
    • Do we know how fragmented the testslave drive is on windows?
    • Try running the timing on try-server with the same hardware and see if this test is just as slow on the same hardware.
    • Is it important that the test actually flush to disk? Could we write it to memory instead? We should take that question back to the places devs and see if we could speed this up that way.


Review current activities

  • wlach has been digging into slow XPCShell tests (bug 617503)
    • It seems as if there's a disk i/o issue which is making places and addon related xpcshell tests really slow on our build slaves. Anything we can do about this?
    • Geolocation test also seems to be somewhat broken (incorrectly tries to connect to google, hanging the test without respecting timeout). bug 674738. Do we need to poke someone about this?
    • Should probably file bug about the nsIProcess test forking 1000 times. Is this really necessary?

Review [buildfaster:?] bugs

Questions

From last time:

  • run 10.5 debug builds on 10.6 machines? It increases capacity of 10.6 pool. Low low priority. Loosely related.
  • shall we break up the current activities section into bug being worked on and bugs in the back burner?

Actions for next 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.
  • wlach to file bugs on other xpcshell test slowness he found
  • wlach to ask places devs if we need all places tests to hit disk
  • wlach to start digging into browser-chrome slow tests