Auto-tools/Projects/Mozbase/Automation-Refactor/Meetings/2013-02-12
From MozillaWiki
< Auto-tools | Projects | Mozbase | Automation-Refactor
Contents
Details
February 12, 2013 @ 11:30am PDT / 2:30pm EDT
dial-in:
- vidyo: Jgriffin's vidyo room
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
The Great Automation Refactor
- Meeting page: https://wiki.mozilla.org/Auto-tools/Projects/Mozbase/Automation-Refactor
- 2013 Q1 Goal to move mochitests atop mozbase (see https://wiki.mozilla.org/Auto-tools/Goals/2013Q1#General_Automation)
- TRACKING BUG: https://bugzilla.mozilla.org/show_bug.cgi?id=775756
- See also: https://wiki.mozilla.org/Auto-tools/Projects/MozBase/Roadmap
Quick Status Updates
- [ahal] Webapp support in mozprofile (see bug 837719 and feel free to give feedback on the patch)
- [ahal] Started work pulling prefs into their own files (bug 830430)
- [jhammel] hooking up mozbase tests to make check (in flight, nearly landed)
- [jhammel] removing duplicate mozinfo/manifestdestiny (WIP)
Issues of the Two Weeks (since you looked at me)
- userChrome/userContent/overlay handling
- is mochitest the only harness that does this? (probably, might not even be needed)
- do we want to use an external css parser like tinycss or cssutils?
- --> no
- Preference interpolation (bug 839527)
- use the "writemozinfo.py" approach? allow users to pass in an interpolation dict? both?
- --> maybe keep things simpler for now, don't get too generic
- Mozrunner -> what to do?
- remote harnesses -> how does it tie in with mozdevice?
- [jhammel] AIUI, this is what wlach is going to do (wlach?)
- --> mozrunner will likely use mozdevice for remote platforms, mozprocess for desktop
- Environment / mozenv?
- --> no mozenv, maybe just make sure all of the launching code (mozrunner, mozprocess, mozdevice) supports environment variables
- remote harnesses -> how does it tie in with mozdevice?
- what sort of communication are we doing to the outside world? (developers, etc)
- one option: collect all changes worth mentioning and send them post-facto to e.g. dev-platform
- of course we should provide links to the relative changeset ranges, bugs, etc.
- -> mail dev-platform when we're near completion; perhaps nowish for a blog post
- simplejson/json on test slaves: https://bugzilla.mozilla.org/show_bug.cgi?id=837983
- RelEng Options:
- deploy to test slaves
- wait for mozharness
- Our options: we don't want to block all the things on this
- do all work requiring simplejson on cedar (this will be most work)
- merging?
- see what we can do to help mozharness along
- some combination
- bug to use Python 2.7 on fedora slaves: 837983
- do all work requiring simplejson on cedar (this will be most work)
- --> Clint to follow up with joduinn about mozharness completion
- RelEng Options:
- https://mxr.mozilla.org/mozilla-central/source/testing/ has a bunch of crap in it
- anyone know about https://mxr.mozilla.org/mozilla-central/source/testing/tests/memtest.py ? https://bugzilla.mozilla.org/show_bug.cgi?id=838079 ? Is there any reason not to kill it?
- mozbase, mozbuild, m-c and python future : do we (or some portion of we) want to meet with gps soon to coordinate efforts? Possible areas:
- populate_virtualenv vs pip: what are our plans? (.pth vs setup, etc)
- packaging: do we want anything here?
- libraries/methodologies to use, to avoid
- templates to create a new package, script, test etc
- documentation: we don't friggin have much; what should it look like
- structured logging: separate meeting