This was a very simple ticket actually. I created a list called FOUNDATIONS in
mediagoblin/db/models.py. This list holds all of the information about rows that
should be created at database initialization. Read the documentation near the
FOUNDATIONS list to understand the proper format for this list.

All of the work is done through a new method on MigrationManager in
mediagoblin/db/migrations_tools.py. This method, `populate_table_foundations`
parses the FOUNDATIONS list and creates the foundations based on the data incl-
uded. This only ever happens when the database is initialized. Migrations to
releases with new Foundations should be very easy just using the basic
database functionality.
I actually had to do a bit more work than I thought, because I needed to account
for plugins. In this commit I changed the MigrationManager and DatabaseData ob-
jects to account for FOUNDATIONS in any plugin's (or main program's) models.py
file.
Starting to write unit tests...
In this commit I added a few unittests to account for Foundations. There were
only a few tests I had to add to mediagoblin/tests/test_sql_migrations.py beca-
-use the foundation creation only happens at database initialization.
Merge branch 'ticket-679' of gitorious.org:~npigeon/mediagoblin/npigeons-mediagoblin
I added a few more unitests in this commit. It now confirms that even after mi-
-gration, there is only one of each Foundation object.
Merge remote-tracking branch 'tilly-q/ticket-679'
typo fix in foundations branch