Add / adjust copyright headers on all files.


-  Python files already have appropriate AGPL header, except need
   adjustment to provide exception for HTML (maybe also CSS for the
   sake of clarity?) files. See:
   `http://www.gnu.org/licenses/gpl-faq.html#WMS <http://www.gnu.org/licenses/gpl-faq.html#WMS>`_
   though we will probably need to make some adjustments to that.
-  HTML templates should contain CC0 header. See:
   `http://wiki.creativecommons.org/CC0\_FAQ#May\_I\_apply\_CC0\_to\_computer\_software.3F\_If\_so.2C\_is\_there\_a\_recommended\_implementation.3F <http://wiki.creativecommons.org/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F>`_
-  Move COPYING to AGPLv3.txt
-  Download
   CC0\_1.0.txt:http://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
-  Create a new COPYING which describes that python code is under
   AGPLv3 (AGPLv3.txt) w/ exception for HTML templates, Javascript
   under AGPLv3 w/ exception for HTML, and HTML templates / images /
   CSS of base theme all under CC0 (CC0\_1.0.txt)

If we end up having CSS files by the time this is written we should
also add headers to these, but do this in the style listed at the
bottom of this post:
`https://creativecommons.org/weblog/entry/27094 <https://creativecommons.org/weblog/entry/27094>`_

Make it super, super simple to set up a development environment.

Unfortunately, as much as I prefer virtualenv for deployment, I
think it requires too much special python packaging knowledge to
maintain. I'm going to add support for / rewrite the hacking\_howto
section for using zc.buildout. Virtualenv will still be an option
(and that will be mentioned), but I'm fairly sure that zc.buildout
is the only option that makes working with such a codebase doable
for people who **aren't** deeply familiar with python packaging.

Also need to check in a basic working paste deploy config file to
make running the server simple.

(We'll probably keep virtualenv instructions in the deployment
guide but that's a ways off.)

We need to start testing views to make sure they work right. Right
now we should create a "test app" to start testing things in.

Use webtest:
`http://pythonpaste.org/webtest/ <http://pythonpaste.org/webtest/>`_

The testing app should be importable from something like:

            from mediagoblin.tests.tools import get\_test\_app
            test\_app, webtest\_app = get\_test\_app()




where the test\_app is the MediaGoblinApp instance and webtest\_app
is a wrapped instance in webtest.

The testapp should do the following things:


-  create a new database with the database name
   '**mediagoblinunittests**' or something with the default connection
   settings, dumping an old database if it exists
-  Attach a mediagoblin.app.MediaGoblinApp instance to webtest with
   that database... see the structure of paste\_app\_factory to see
   how to do this
-  create a public\_store and a queue\_store that write to
   temporary directories. Use tempfile.mkdtemp() to create these
   directories
-  when calling setup\_celery\_from\_config it should make sure the
   mongodb database that it calls is the *mediagoblinunittests*
   database we created.

One note: cache the database connection in a global variable like
mediagoblin.tests.tools.DATABASE\_CONNECTION and also note whether
celery is set up in mediagoblin.tests.tools.CELERY\_IS\_SET\_UP...
we should only set up celery once :)