I'm mostly OK with this. I do not get why "common" makes sens for APIObject? To my ears api.Object works better. Also, I have an allergic reaction to "common", "core", "base", and so on.

apitools -> api/tools?

or maybe apitools + common -> runtime?

This generally LGTM from a packaging perspective. I prefer common.Object to api.APIObject since its less redundant, but like @thockin, I am not the biggest fan of "common". I also preferred api/tools to apitools. apitools feels like it breaks Go conventions of single word package names for most libraries. If we are making this change, would like to do it ASAP so we can all avoid rebase hell.

The idea with making a "common" package was that they were "versionless" objects which could be used from any version of an api. Definitely the common object should not go into the main api package, because then everything would have to depend on the main api package. I could see it going into the apitools package.

apitools + common -> runtime?

Is everyone else cool with this rename? If so I'll do it quickly.

LGTM

OK, rebase & rename done.

Hm, travis is failing consistently at tip. I put in a change to disable travis at tip.

(Failing due to detecting races that seem to be in the coverage module, not our tests.)

I'm self-merging this since I now see that the travis failure at tip has been happening for a while now.

LGTM