Confirmed users
656
edits
(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 |