Identify key non-browser Launchpad clients and write docs for how to test/QA with them

OEM uses 5 API scripts currently. I've passed this information to Diogo.

Based on the discussion I had with different groups inside canonical and a private email thread started by Jono, here's the list of applications under consideration (not all of those will make the final list):

• package branch uploader <lp:udd>
• bzr's launchpad plugin
• lp-land from bzr-pqm
• lp:lptools
• bughugger <https://launchpad.net/bughugger>
• lp:~landscape-devel-team/landscape-devel/trunk
• lp:~canonical-isd-hackers/fa-django-integration/trunk
• IRC bots
• ubuntu-dev-tools package <https://launchpad.net/ubuntu-dev-tools/>
• ubuntu-archive-tools
• Hydrazine (bugclient and feed-pqm) <https://launchpad.net/hydrazine>
• scripts/sis-changes from lp:ubuntu-cve-tracker
• common/lpl_common.py from lp:ubuntu-qa-tools
• Tarmac <https://launchpad.net/tarmac>
• Arsenal <https://launchpad.net/arsenal>
• Checkbox <https://launchpad.net/checkbox>
• Apport <https://launchpad.net/apport>
• OEM's Bug triaging tool - Alex K & Brent F
• OEM's Project Setup - Joey
• OEM's Security and Infrastructure - Cody & Nic V
• OEM's Build system - Cody

I think we need to have two categories of SLA here:
  1. One focused on the Ubuntu platform, e.g. A rollout of Launchpad should never break Canonical-supported packages in Canonical-supported releases of Ubuntu
  2. One focused on Canonical processes.

I quite like my example for point 1, and think we should make that our agreement.

I don't have a good idea for point 2, partly because there's so much fragmentation in launchpadlib-based developer tools. My guess is that it should be something like "if you rely on the production server, you won't get burned".

There's also a third kind of thing, I think. James Westby's package branch uploader is critical to the Ubuntu development process, but I see it as being a part of Launchpad itself. It's just a part that's written with launchpadlib and maintained in a separate tree. I'm willing to be convinced that it's a special case of 2 though.

In terms of concrete actions, here are my recommendations:
  * Diogo should go ahead and figure out a way of guaranteeing apport with an eye to providing a more general process.
  * If there are no objections, I'll put the SLA for #1 on the dev wiki, blog about it, email ubuntu-devel yada yada yada
  * I'll talk to U1 folk, see if they've got the same problem and if so how we can share solutions

jml

So I'm going to wontfix this. Why? Because manual QA at the rate we're going is basically impossible. If there are tests that the owners of those scripts want in our QA process, we'll be delighted to accept patches that cause our test suite / CI environment to exercise the code path they need.