Notes to consider for README

[cookrn]

* this would just be a regular project that could live on github like a web
app would. just like rails projects depend on a specific rails version and,
if you want to change the rails version, you might have to change parts of
your project, petra projects depend on specific versions of
ansible/vagrant. if you want to use a new version of vagrant/ansible, you
might have to change parts of a petra-generated project.

* i need to work on the language for what the framework provides right now
so people have a better idea of _how_ it helps and makes things easier

* this framework would be for specifying your server builds so that, for
example, capistrano just works seamlessly when you go to use it. ansible is
used in lieu of chef.

Vagrant is used to run/test all of your ansible playbooks locally. You boot
a virtual machine and run your playbooks against it to see if they work
correctly and the expected state is present. For example, build an
appserver vm locally and do a cap deploy from your rails project _to_ the
vm!

* I don't think it would hurt, so long as they have an easy way to
customize code and still merge upstream changes when necessary.
* It would make it easier for me, and I have limited experience with these
tools -- can't speak for others.
* No idea... honestly, I think if I knew more about all the options out
there, I'd be less terrified to let go of capistrano or chef and old sorts
of tools.

I'm still a little confused about how vagrant is to be used. Is it meant to
manage VMs in the cloud for production, or are you actually supposed to
deploy locally as your development environment/CI?

[cookrn]

More:

"If the question is, should everything be checked into version control, including system configurations? And should those system configurations be included in the same repo as the application code? The answers are: absolutely yes. This is the only way to ensure that the application in the repo is deployable."