Pulp

Update the docs [0] to reflect the change in branching strategy that we had discussed. Here is the summary:

Each X.Y release will have one branch. Perhaps we call it X.Y-dev to be consistent with current naming. 
All work for the X.Y stream will be merged to this branch.

Beta, RC, and GA releases will be represented as tags only.

When it is time to do a beta release, the current tip of X.Y-dev will be tagged and built. If a beta or RC
fails testing, appropriate fixes are applied to X.Y-dev, and a new build can be made. Any additional fixes
not blocking the previous beta, which happen to have been merged to X.Y-dev since the previous build,
*will be included*. Betas are no longer frozen to just blocking fixes.

Hotfix: If an important hotfix must go out quickly, a branch will be created from the previous Z release tag.
The fix will be made (via PR from a personal fork to the hotfix branch), a new tag will be built from the tip
of the hotfix branch, and the hotfix branch can be merged to X.Y-dev.

Merging a PR forward is only required once per X.Y release, and we can guarantee that X.(Y-1) is always
fully merged into X.Y. This should be about as easy as merging could be. Example: I fix a bug in 2.7-dev. I
know it will land in the next 2.7 build, but I don't need to care which. I merge my change to 2.8-dev if it
exists, and master. 2.7-dev is guaranteed to already be fully merged into 2.8-dev and master, so the merge
should be uneventful.

Once the documentation is updated, an email needs to be sent out to the pulp-list with [devel] tag in subject. The email should explain that there has been a change in the branching strategy and point readers to the newly updated documentation.

[0] - http://pulp.readthedocs.org/en/latest/dev-guide/contributing/branching.html