From MozillaWiki
Jump to: navigation, search


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


Backchannel #ateam on

Take meeting notes here: Then copy and paste them below afterwards

Meeting Notes

Quick Status Updates

Bugs from

 [mozprofile] AddonManager should only optionally cleanup on __del__
 [mozprocess] ProcessHandler should front-end more subprocess API
 [mozprofile] Profile.pop_preferences() has wrongly hardcoded user.js
 [mozprofile] add interpolation function and fix screwy m-c interpolation
  • Bug 913217 -
 [mozrunner] debuggers and debugger_args should be be added to __all__
 [mozrunner] mozrunner cleanup from mochitest on mozbase
  • bug 916512
 [mozrunner] mozrunner should use -foreground at least for mac
 [mozprofile] rectify DEFAULT_PORTS to be actual default ports, not
 proxied ports

- 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: ^

  • Questions from wlach spurred by
    • 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: ; 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