I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption.
I think "backporting" is an entirely different issue, let alone "automatic" backporting. What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering. By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :)
I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year. Regards, Martin