Auto-tools/Projects/Mozbase/Automation-Refactor/Meetings/2013-02-12: Difference between revisions

(stub a new meeting)
 
 
Line 11: Line 11:


= Meeting Notes =
= Meeting Notes =
 
== The Great Automation Refactor ==
* what sort of communication are we doing to the outside world? (developers, etc)
* Meeting page: https://wiki.mozilla.org/Auto-tools/Projects/Mozbase/Automation-Refactor
** one option: collect all changes worth mentioning and send them post-facto to e.g. dev-platform
* 2013 Q1 Goal to move mochitests atop mozbase (see https://wiki.mozilla.org/Auto-tools/Goals/2013Q1#General_Automation)
** of course we should provide links to the relative changeset ranges, bugs, etc.
* 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
* 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
** --> Clint to follow up with joduinn about mozharness completion
* 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
Confirmed users
656

edits