There were several calls into code in the externalbugtracker module that passed BugWatch objects. Two things:
1. The *only* field of these BugWatch objects ever referenced is `remotebug`. I've changed all methods to accept a `remote_bug_id` parameter instead of `bug_watch`, and all call-sites have been updated accordingly.
2. These are database/model objects. There is a nascent plan to also package and run the externalbugtracker code as a job-running service, outside of the familiar core Launchpad application. It's much easier to pass/serialize a `remote_bug_id` parameter (always a string) into a job spec than a model object.
There were several calls into code in the externalbugtracker module that passed BugWatch objects. Two things:
1. The *only* field of these BugWatch objects ever referenced is `remotebug`. I've changed all methods to accept a `remote_bug_id` parameter instead of `bug_watch`, and all call-sites have been updated accordingly.
2. These are database/model objects. There is a nascent plan to also package and run the externalbugtracker code as a job-running service, outside of the familiar core Launchpad application. It's much easier to pass/serialize a `remote_bug_id` parameter (always a string) into a job spec than a model object.
Lint free.
Test: bin/test -vvt 'checkwatch| bug-?watch| bug-?track| bug-?import| bug-?notificati on'