Merge pull request #339 from igorw/docs

Docs: finish repositories, add community chapter

README.md

@@ -97,6 +97,10 @@ merged. This is to ensure proper review of all the code.
 
 Fork the project, create a feature branch, and send us a pull request.
 
+To ensure a consistent code base, you should make sure the code follows
+the [Coding Standards](http://symfony.com/doc/2.0/contributing/code/standards.html)
+which we borrowed from Symfony.
+
 If you would like to help take a look at the [list of issues](http://github.com/composer/composer/issues).
 
 Community

doc/04-schema.md

@@ -288,7 +288,7 @@ Example:
                 "source": {
                     "url": "http://smarty-php.googlecode.com/svn/",
                     "type": "svn",
-                    "reference": "trunk"
+                    "reference": "tags/Smarty_3_1_7/distribution/"
                 }
             }
         }

doc/05-repositories.md

@@ -148,6 +148,116 @@ The VCS driver to be used is detected automatically based on the URL.
 
 ### PEAR
 
+It is possible to install packages from any PEAR channel by using the `pear`
+repository. Composer will prefix all package names with `pear-{channelName}/` to
+avoid conflicts.
+
+Example using `pear2.php.net`:
+
+```json
+{
+    "repositories": [
+        {
+            "type": "pear",
+            "url": "http://pear2.php.net"
+        }
+    ],
+    "require": {
+        "pear-pear2/PEAR2_HTTP_Request": "*"
+    }
+}
+```
+
+In this case the short name of the channel is `pear2`, so the
+`PEAR2_HTTP_Request` package name becomes `pear-pear2/PEAR2_HTTP_Request`.
+
+> **Note:** The `pear` repository requires doing quite a few requests per
+> package, so this may considerably slow down the installation process.
+
 ### Package
 
+If you want to use a project that does not support composer through any of the
+means above, you still can define the package yourself using a `package`
+repository.
+
+Basically, you define the same information that is included in the `composer`
+repository's `packages.json`, but only for a single package. Again, the
+minimally required fields are `name`, `version`, and either of `dist` or
+`source`.
+
+Here is an example for the smarty template engine:
+
+```json
+{
+    "repositories": [
+        {
+            "type": "package",
+            "package": {
+                "name": "smarty/smarty",
+                "version": "3.1.7",
+                "dist": {
+                    "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
+                    "type": "zip"
+                },
+                "source": {
+                    "url": "http://smarty-php.googlecode.com/svn/",
+                    "type": "svn",
+                    "reference": "tags/Smarty_3_1_7/distribution/"
+                }
+            }
+        }
+    ],
+    "require": {
+        "smarty/smarty": "3.1.*"
+    }
+}
+```
+
+Typically you would leave the source part off, as you don't really need it.
+
 ## Hosting your own
+
+While you will probably want to put your packages on packagist most of the time,
+there are some use cases for hosting your own repository.
+
+* **Private company packages:** If you are part of a company that uses composer
+  for their packages internally, you might want to keep those packages private.
+
+* **Separate ecosystem:** If you have a project which has its own ecosystem,
+  and the packages aren't really reusable by the greater PHP community, you
+  might want to keep them separate to packagist. An example of this would be
+  wordpress plugins.
+
+When hosting your own package repository it is recommended to use a `composer`
+one. This is type that is native to composer and yields the best performance.
+
+There are a few different tools that can help you create a `composer`
+repository.
+
+### Packagist
+
+The underlying application used by packagist is open source. This means that you
+can just install your own copy of packagist, re-brand, and use it. It's really
+quite straight-forward to do.
+
+Packagist is a Symfony2 application, and it is [available on
+GitHub](https://github.com/composer/packagist). It uses composer internally and
+acts as a proxy between VCS repositories and the composer users. It holds a list
+of all VCS packages, periodically re-crawls them, and exposes them as a composer
+repository.
+
+To set your own copy, simply follow the instructions from the [packagist
+github repository](https://github.com/composer/packagist).
+
+### Satis
+
+Satis is a static `composer` repository generator. It is a bit like a ultra-
+lightweight, file-based version of packagist.
+
+You give it a `composer.json` containing repositories, typically VCS and package
+repository definitions. It will fetch all the packages that are `require`d from
+these repositories and dump a `packages.json` that is your `composer`
+repository.
+
+Check [the satis GitHub repository](https://github.com/composer/satis) for more
+information.

doc/06-community.md

@@ -0,0 +1,28 @@
+# Community
+
+We have a lot of people using composer, and also many contributors to the
+project.
+
+## Contributing
+
+If you would like to contribute to composer, please read the
+[README](https://github.com/composer/composer).
+
+The most important guidelines are described as follows:
+
+> All code contributions - including those of people having commit access - must
+> go through a pull request and approved by a core developer before being
+> merged. This is to ensure proper review of all the code.
+>
+> Fork the project, create a feature branch, and send us a pull request.
+>
+> To ensure a consistent code base, you should make sure the code follows
+> the [Coding Standards](http://symfony.com/doc/2.0/contributing/code/standards.html)
+> which we borrowed from Symfony.
+
+## IRC / mailing list
+
+The developer mailing list is on [google groups](http://groups.google.com/group
+/composer-dev) IRC channels are available for discussion as well, on
+irc.freenode.org [#composer](irc://irc.freenode.org/composer) for users and
+[#composer-dev](irc://irc.freenode.org/composer-dev) for development.