Mozmill Meeting: QA work week bash

Review of 2.0 features

We should prioritize items as MUST HAVE and nice to have
I imagine there are some Mozmill development must have's and some QA must haves as well.
The goal here is to get a concrete list of things (hopefully about 10) that 2.0 must do. That will become the roadmap.
Mozrunner has been refactored into multiple packages: https://bugzilla.mozilla.org/show_bug.cgi?id=575436 ; Mozmill will be broken down a bit too
worth talking about manifests? https://bugzilla.mozilla.org/show_bug.cgi?id=585106

What tests need to go into m-c? Criteria:
- tests must pass reliably
- tests must only hit mozilla.org URLs if they touch network
- https://bugzilla.mozilla.org/show_bug.cgi?id=569813 may block addon tests
- I think we only care about minefield
Does mozmill truly need to live in m-c? Clint's starting that fight on dev.platform right after this note.
- ideally, all external tests+harnesses would not live in m-c but in an e.g. FTP location

Currently the API looks like EventHandler: http://github.com/k0s/mozmill/blob/pluggable/mozmill/mozmill/handlers.py . This class isn't used anywhere, it is just a spec. I have moved on this branch logging and reporting to http://github.com/k0s/mozmill/blob/pluggable/mozmill/mozmill/logger.py and http://github.com/k0s/mozmill/blob/pluggable/mozmill/mozmill/report.py respectively. This code does work; we can talk about details in the meeting and see if this is enough or if we want something different.

option groups: do we want them? See https://bugzilla.mozilla.org/show_bug.cgi?id=524815 ; We could split into option groups, one for mozrunner, one for jsbridge, one for mozmill, and one for each mozmill plugin
should we consolidate into one command line script? Currently we have mozmill, mozmill-restart, and mozmill-thunderbird; Is there any reason not to do mozmill --restart and mozmill --thunderbird? Note that this will only be a command-line change; underlying logic will be unaffected