Details

June 4th, 2013 @ 11:30am PDT / 2:30pm EDT

dial-in:

• vidyo: Jgriffin's vidyo room
  • guest link: https://v.mozilla.com/flex.html?roomdirect.html&key=vjLJS93feY9p

Backchannel #ateam on irc.mozilla.org

Take meeting notes here: https://etherpad.mozilla.org/great-automation-refactor Then copy and paste them below afterwards

Meeting Notes

Quick Status Updates

• [ahal] Latest patch for b2g mochitest refactor is up
  • https://bugzilla.mozilla.org/show_bug.cgi?id=865349#c12
  • Waiting for bug 855893 to land so I can test out the mozbase parts on try
• [jhammel] after more difficulties, `make check` is again close
  • https://bugzilla.mozilla.org/show_bug.cgi?id=790765
• manifestdestiny dupe mostly works; trying on android (again)
  • https://bugzilla.mozilla.org/show_bug.cgi?id=707976
  • I still don't really understand how the mozinfo import works (but haven't looked closely)
  • 'twould be nice to get rid of these horrible hacks; when?

Issues of the Two Weeks (since you looked at me)

• CLI parsing
  • Where should it live/how should it be handled in a post automation.py world?
  • Should we create a new module? Or should each harness take care of its own?
  • I think jhammel already has a module? <insert link>
    • [jhammel: nope, MozOptions has been talked about; we should spec out what we need here (see below)]
  • What about common options?
    • [jhammel: again, this would be in some combination of MozOptions and MozTest, in theoretical future]
  • optparse is pretty crappy -- if we do write/use our own cli parsing library, let's try not to lock ourselves into it. argparse (introduced in python 2.7) is MUCH better and more flexible.
    • [jhammel: still blocked on python 2.7, although the module is available for older pythons, just not in stdlib. For that matter, argparse ain't perfect either]
  • mach might be something else to consider using for this sort of thing (https://github.com/indygreg/mach), although it probably only solves part of the problem.
    • [jhammel: mach is also slated for `%prog [options] command [options] <args>` style programs, which may/may not fit our need]
  • There's already MozProfileCLI: https://github.com/mozilla/mozbase/blob/master/mozprofile/mozprofile/cli.py#L21 and mozrunner.CLI which inherits from it: https://github.com/mozilla/mozbase/blob/master/mozrunner/mozrunner/runner.py#L262
• Mozb2g, can we remove it?
  • Adds a dependency to marionette
  • This has been filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=852235 . I (wlach) would like to have a plan to meaningfully replace it before removing it.
    • DECISION: wait for ahal's mozrunner refactor to finish, hopefully will provide a replacement for what wlach is using mozb2g for in eideticker
• Where to put shared code that doesn't belong in mozbase?
  • [jhammel: depends on the code?]
    • wait and see, but lean towards creating separate in-tree packages for each piece of funcitonality (e.g., MochitestServer); add these to both packages.txt for in-tree virtualenv population, and tests.zip
    • [jhammel: it would be *really* nice to document how to do this; preferably, this would be clean and kinda one-step; let us not also forget mozharness package server installation]
• Intern projects?
  • cmanchester: Machine readable logging. Some design notes from ctalbert/ted/gps/ahal/wlach here: https://etherpad.mozilla.org/structured-logging-notes
  • mozprocess test(s) is/are sucky; not a full termm project, but would be nice to get some love
  • paralellizing xpcshell tests?
  • mach targets
• Milestone review
  • https://wiki.mozilla.org/Auto-tools/Projects/Mochitest_on_Mozbase#Goal_2013_Q2
• MozBase unit tests GSOC project (ffledging)? What to work on and what order?
  • (ctalbert): ffledgling and I have a schedule here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ffledgling/4001

It is: Week 1: Unit tests for Mozfile Week 2: Unit tests for Mozinfo, Mozlog Week 3: Unit tests for Moznetwork, Mozinstall Week 4: Unit tests for Mozhttpd* Week 5: Unit tests for Mozdevice* Week 6: Unit tests for Mozdevice* Week 7: first Catch-up period Week 8: Bundling device emulator to run tests with the SUTAgent and adb Week 9: Unit tests for Mozprofile* Week 10: Unit tests for Mozprocess* Week 11: Second Catch up period Week 12: Unit tests for Mozrunner* (if possible. else Catch-up I've noted that Mozrunner may be dropped if we run out of time. I would like him to write tests for as many of the publicly available APIs from the mozbase modules as possible this summer. Ideally, we will do them all. Pragmatically, we will do some (hopefully) high percentatge of them. I had him order things this way so he hits a few small, easy modules first and then dives into the higher priority ones that are more difficult next. The most difficult ones are saved for last, and may be time boxed.