Details

September 17, 2013 @ 11:30am PDT / 2:30pm EDT

dial-in:

• vidyo: Jgriffin's vidyo room
  • guest link: https://v.mozilla.com/flex.html?roomdirect.html&key=vjLJS93feY9p

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

Bugs from

• [FIXED] https://bugzilla.mozilla.org/show_bug.cgi?id=911218

 [mozprofile] AddonManager should only optionally cleanup on __del__

• https://bugzilla.mozilla.org/show_bug.cgi?id=912285

 [mozprocess] ProcessHandler should front-end more subprocess API

• [FIXED] https://bugzilla.mozilla.org/show_bug.cgi?id=912338

 [mozprofile] Profile.pop_preferences() has wrongly hardcoded user.js

• https://bugzilla.mozilla.org/show_bug.cgi?id=913152

 [mozprofile] add interpolation function and fix screwy m-c interpolation

• Bug 913217 -

 [mozrunner] debuggers and debugger_args should be be added to __all__

• https://bugzilla.mozilla.org/show_bug.cgi?id=913970

 [mozrunner] mozrunner cleanup from mochitest on mozbase

• bug 916512

 [mozrunner] mozrunner should use -foreground at least for mac

• https://bugzilla.mozilla.org/show_bug.cgi?id=916517

 [mozprofile] rectify DEFAULT_PORTS to be actual default ports, not
 proxied ports

• Mirroring strategy, bug 746243 – port Mochitest to Mozbase https://bugzilla.mozilla.org/show_bug.cgi?id=746243 :

- work around bugs in situ; so far, no hard blockers have been found - ticket upstream work (concurrently) - land m-c fix - fix pertinent upstream issues - bump versions & mirror -> m-c (in this case, mozprofile, mozprocess, mozrunner)

Issues of the Two Weeks

Resolved, I (jhammel) believe, at least in theory: https://bugzilla.mozilla.org/show_bug.cgi?id=912200 ^

• Questions from wlach spurred by https://bugzilla.mozilla.org/show_bug.cgi?id=911218
  • What is the use case for "cleaning up" profiles created by mozprofile? Where do we need this?
  • If there is somewhere where we actually need to do this, should we be depending on __del__ for it to happen?

jhammel's take: in brief, - not cleaning up (or relying on consumers to cleanup) for, notably, persisted profiles introduces a different gotcha --> [wlach] right, so who is using persisted profiles? :) - in general, it'd be nice to have reliable cleanup; AFAIK, __del__ doesn't absolutely guarantee this....but it isn't necessarily the worst answer possible. The contextmanager approach is another way to go: http://docs.python.org/2/library/stdtypes.html#typecontextmanager ; http://docs.python.org/2/reference/datamodel.html#context-managers In general, I hope we can agree to have idempotent cleanup methods, whatever they're called; in this case, they can be called explicitly if needed or as part of __del__ or __exit__ or other strategy

• Goal review (if needed)
• Structured logging next steps
  • https://bugzilla.mozilla.org/show_bug.cgi?id=916295
  • https://etherpad.mozilla.org/structured-logging-future
  • https://etherpad.mozilla.org/jgraham-structured-logging
• Purpose of this meeting
• mozconfiguration (http://k0s.org/mozilla/hg/configuration)
  • part of mozbase?
  • use cases in automation?