diff --git a/committing.rst b/committing.rst
--- a/committing.rst
+++ b/committing.rst
@@ -186,7 +186,7 @@
 automatically closed as "fixed".
 
 Working with Mercurial_
------------------------
+=======================
 
 As a core developer, the ability to push changes to the official Python
 repositories means you have to be more careful with your workflow:
@@ -342,30 +342,26 @@
 .. _share extension: http://mercurial.selenic.com/wiki/ShareExtension
 
 
-Forward-Porting
+Active branches
 ---------------
 
-If the patch is a bugfix and it does not break
-backwards-compatibility *at all*, then it should be applied to the oldest
-branch applicable and forward-ported until it reaches the in-development branch
-of Python (for example, first in ``3.2``, then in ``3.3`` and finally in
-``default``). A forward-port instead of a back-port is preferred as it allows
-the :abbr:`DAG (directed acyclic graph)` used by hg to work with the movement of
-the patch through the codebase instead of against it.
+If you do ``hg branches`` you will see a list of branches.  ``default`` is the
+in-development branch, and is the only branch that receives new features.  The
+other branches only receive bug fixes (``2.7``, ``3.2``, ``3.3``), or security
+fixes (``2.6``, ``3.1``).  Depending on what you are committing (feature, bug
+fix, or security fix), you should commit to the oldest branch applicable, and
+then forward-port until the in-development branch.
 
-Note that this policy applies only within a major version - the ``2.7`` branch
-is an independent thread of development, and should *never* be merged to any
-of the ``3.x`` branches or ``default``. If a bug fix applies to both ``2.x``
-and ``3.x``, the two additions are handled as separate commits. It doesn't
-matter which is updated first, but any associated tracker issues should be
-closed only after all affected versions have been modified in the main
-repository.
 
-.. warning::
-   Even when porting an already committed patch, you should **still** check the
-   test suite runs successfully before committing the patch to another branch.
-   Subtle differences between two branches sometimes make a patch bogus if
-   ported without any modifications.
+Merging order
+-------------
+
+There are two separate lines of development: one for Python 2 (the ``2.x``
+branches) and one for Python 3 (the ``3.x`` branches and ``default``).
+You should *never* merge between the two major versions (2.x and 3.x) ---
+only between minor versions (e.g. 3.x->3.y).  The merge always happens from
+the oldest applicable branch to the newest branch within the same major
+Python version.
 
 
 Porting Within a Major Version