Comment 1 for bug 628832

I talked with Stuart Metcalfe and Salgado about this. Highlights follow.

Right now, the shipit code itself relies on these tables: Account, EmailAddress, Country, Karma, and (in order to get to Person).

The karma is used to decide whether or not the user is "trusted" on shipit. Trusted users are allowed to ask for more CDs than regular users. A user is trusted if they have X karma or are ubuntu members.

Karma is in the webservice API, but not the way that shipit uses it (it counts karma entries, while the webservice gives total karma points).

One way of simplifying the problem would be to get approval to ignore karma. Then it could just get team membership from openid to see if the user were a member of the ubuntu team. Circumstances might make this acceptable. It will simply mean fewer people allowed to order more than a couple CDs.

Team membership and the account and email address information can be obtained from openid. Alternatively, and perhaps more easily, shipit could share access to the replicated tables that the openid provider uses.

That would just leave the Country table, which is relatively static, and would not have to stay in sync with Launchpad.

All three of us agree at this time that it would make sense under the current circumstances to have shipit fork Launchpad code, rather than trying to keep up with trunk.

All of the above doesn't sound too bad. However, the biggest risk is that shipit relies on some Launchpad code, and that Launchpad code might fall over when the rest of the database is not around. We don't know. If it does fall over, we don't know how easy it will be to fix it.

Salgado will be happy to offer advice, but will not be available for any of the actual work.