It wasn't clear to me after reading the "Forward Porting" section exactly what was going on.  Nick Coghlan spelled it out for me in a private email, and suggested that maybe this stuff should be in the devguide proper.  Here's some specific stuff that I didn't understand until Nick explained it to me with simple words:

* 2.x and 3.x have separate heads in the same repository
* Since they're totally divorced, the order you check in to 2.x and 3.x does not matter
* DO NOT MERGE between 2.x and 3.x
* Branches that are in security-fix-only mode (e.g. 3.1) don't get bugfixes or documentation fixes (surely mentioned elsewhere, but I personally would have been helped with a reminder)

I suggest it'd be clearer to start with discussing "2.x and 3.x are separate heads", and *then* move on to "But when merging changes solely inside a major version" and talk about forward-porting.

Would you be interested in a patch?

Can you paste the email for a starting point?

This was from memory, so don't take it as gospel as far as the current security-fix-only branches go, but here's what I sent to Larry:

-----------------
We maintain two independent heads in hg: 2.7 and default

3.2 is open for general bugfixes

2.5 (IIRC), 2.6 and 3.1 are open for security fixes

Security fixes (if applicable to both heads) go:
2.5 -> 2.6 -> 2.7
3.1 -> 3.2 -> default

General bug fixes (if applicable to both heads) go:
2.7
3.2 -> default

New features are added to default only

The relative ordering of 2.x and 3.x changes doesn't really matter -
the important thing is not to merge them in *either* direction. I
think you can theoretically do cherry-picking with Hg, but most people
seem to just do independent commits to the two streams.
-----------------

What follows is the original email from Nick.

--

We maintain two independent heads in hg: 2.7 and default

3.2 is open for general bugfixes

2.5 (IIRC), 2.6 and 3.1 are open for security fixes

Security fixes (if applicable to both heads) go:
2.5 -> 2.6 -> 2.7
3.1 -> 3.2 -> default

General bug fixes (if applicable to both heads) go:
2.7
3.2 -> default

New features are added to default only

The relative ordering of 2.x and 3.x changes doesn't really matter -
the important thing is not to merge them in *either* direction. I
think you can theoretically do cherry-picking with Hg, but most people
seem to just do independent commits to the two streams.

If the devguide doesn't align with the above, then a tracker issue
pointing that out would be handy :)

New changeset 0541f815d016 by Nick Coghlan in branch 'default':
Update NEWS entry policy based on recent mailing list discussion and forward porting section based on Issue 13105
http://hg.python.org/devguide/rev/0541f815d016

The devguide actually did align with what I said in my email, but this wasn't clear if you only read the "Forward Porting" section (you had to read the "Porting Between Major Versions" section further down the page as well).

I added a new paragraph to the forward porting section so it describes the whole policy, leaving the following two sections to cover the mechanics of actually handling that with Mercurial.