Auto-tools/Projects/Mozbase/Automation-Refactor/Meetings/2013-06-18: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 36: Line 36:
** manifestdestiny/mozprocess lots of work to do (tracking bugs?)
** manifestdestiny/mozprocess lots of work to do (tracking bugs?)


== Decisions for /the future/ ==
==== Decisions for /the future/ ====
1. CI failures: to note on bug?
* CI failures: to note on bug?
-- add to policy :)
** add to policy :)
2. mock, etc, libraries in testing?
* mock, etc, libraries in testing?
** leaning towards not using external dependencies unless absolutely necessary
 
==== Mozbase, Packaging, Mirroring and the Future of M-C ====
==== Mozbase, Packaging, Mirroring and the Future of M-C ====
==== Areas of Development ====
==== Areas of Development ====

Latest revision as of 19:26, 18 June 2013

Details

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

dial-in:

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] using in-tree mozbase for test harnesses now (bug 855893)
  • [ahal] import mozbase by adding modules to sys.path instead of crazy hack
  • [jhammel] make check locally works, try run coming soon, optimistic it'll stick this time
  • [chmanchester] starting on the javascript side (log4moz.js): see https://bugzilla.mozilla.org/show_bug.cgi?id=884397
  • [jmaher] close to finishing manifests for mochitests (bug 852416)
  • [ted] working on mozinfo integration with test harnesses, added find_and_read_json method

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

  • Agenda for mozbase work week? Propose items below
    • brainstorm the creation of a mozbase "manifesto" -- both a high-level statement vision of the purpose of the project, and a detailed roadmap of how to make it live up to that vision [jhammel: a big +1][nalexander: another big +1 here]
      • what components are we missing, if any?
      • where should shared code live that doesn't belong in a mozbase component?
      • [jhammel: I would (OTTOMH) go for a manifesto with a clear, short exec summary==vision statement and then a longer (not very long) high-level explanation of how all this fits together: an aggressive plan of attack to the stars]
      • I would tend
    • machine readable logging - how to get off to a running start? [chmanchester]
    • figure out and prototype approach to multiprocessing in tests? likewise get off to running start [mineahdb]
    • strategizing on how to write tests for ffledging's gsoc project? [jhammel: +1; i'd be willing to triage andor audit/help triage andor audit to this end]
    • finish up mozrunner refactor and make sure it is a viable replacement for mozb2g
      • mozb2g/eideticker, can we replace it? What's the best path forward?
      • moztest? common code etc.
    • manifestdestiny/mozprocess lots of work to do (tracking bugs?)

Decisions for /the future/

  • CI failures: to note on bug?
    • add to policy :)
  • mock, etc, libraries in testing?
    • leaning towards not using external dependencies unless absolutely necessary

Mozbase, Packaging, Mirroring and the Future of M-C

Areas of Development

Mozbase has essentially two domains in need of development effort: improvement of the mozbase software and integration of the mozbase packages with (largely legacy) targetted consumers.

  • manifestdestiny
  • mozprocess
  • tests (ffledgling)