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

From MozillaWiki
Jump to navigation Jump to search
(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

Latest revision as of 20:16, 12 February 2013

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

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
  • 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
Retrieved from "https://wiki.allizom.org/index.php?title=Auto-tools/Projects/Mozbase/Automation-Refactor/Meetings/2013-02-12&oldid=518298"