Update the setup and PR lifecycle pages (python#265)

* Update the setup page and the quick guides.

* Working and markup tweaks.

* Remove the "Tool Setup" section.

* Rename the "Creating" section to "Introduction".

* Reorganize info about patchcheck.

* Rename and move the "Preparation" section to "Making good PRs".

* Fix headers levels (by rotating quotes).

* Remove outdated comment.

* Move and refactor the sections about commits.

* Fix markup and long lines.

* Convert the step-by-step guide to a bullet list.

Author: ezio-melotti

committing.rst

@@ -57,54 +57,8 @@ passes before merging any code changes.
 Patch checklist
 '''''''''''''''
 
-Along with running the tests, a simple automated patch checklist, ``patchcheck``,
-guides a developer through the common patch generation checks. To run
-``patchcheck``:
-
-   On *UNIX* (including Mac OS X)::
-
-      make patchcheck
-
-   On *Windows* (after any successful build)::
-
-      python.bat Tools/scripts/patchcheck.py
-
-The automated patch checklist runs through:
-
-* Are there any whitespace problems in Python files?
-  (using ``Tools/scripts/reindent.py``)
-* Are there any whitespace problems in C files?
-* Are there any whitespace problems in the documentation?
-  (using ``Tools/scripts/reindent-rst.py``)
-* Has the documentation been updated?
-* Has the test suite been updated?
-* Has an entry under ``Misc/NEWS.d/next`` been added?
-* Has ``Misc/ACKS`` been updated?
-* Has ``configure`` been regenerated, if necessary?
-* Has ``pyconfig.h.in`` been regenerated, if necessary?
-
-The automated patch check doesn't actually *answer* all of these
-questions. Aside from the whitespace checks, the tool is
-a memory aid for the various elements that can go into
-making a complete patch.
-
-
-Commit Style
-------------
-
-.. move this to pullrequest
-
-Once a change patch is ready and tested, it can be committed to the repository.
-We usually prefer to put a whole feature or bugfix into a single commit, but no
-more.  In particular:
-
-* Do **not** fix more than one issue in the same commit (except, of course, if
-  one code change fixes all of them).
-* Do **not** do cosmetic changes to unrelated code in the same commit as some
-  feature/bugfix.
-
-It is of course okay to pile up several commits to one branch and merge them
-into another in one commit.
+You should also :ref:`run patchcheck <patchcheck>` to perform a quick
+sanity check on the changes.
 
 
 Handling Others' Code
@@ -238,37 +192,6 @@ allowed here because news entries are meant to be as readable as possible
 unprocessed.)
 
 
-Commit Messages
----------------
-
-.. move to pullrequest
-
-Every commit has a commit message to document why a change was made and to
-communicate that reason to other core developers. Python core developers have
-developed a standard way of formatting commit messages that everyone is
-expected to follow.
-
-Our usual convention mimics that used in news entries (it is actually common to
-start by pasting the news entry into the commit message). The only key
-difference when compared to a news entry is the inclusion of the issue number
-as the beginning of the commit message. Here is an example::
-
-   bpo-42: the spam module is now more spammy.
-
-   The spam module sporadically came up short on spam. This change
-   raises the amount of spam in the module by making it more spammy.
-
-   Thanks to Monty Python for the patch.
-
-The first line or sentence is meant to be a dense, to-the-point explanation
-of what the purpose of the commit is.  If this is not enough detail for a commit,
-a new paragraph(s) can be added to explain in proper depth what has happened
-(detail should be good enough that a core developer reading the commit message
-understands the justification for the change).  Also, if a non-core developer
-contributed to the resolution, it is good practice to credit them.
-
-
-
 Working with Git_
 =================