As I said before, the main assumption in my suggestion is that there are things 
in trunk that "really should" be in some releasable version, stuff significant 
enough to warrant the work, but is "impossible" to be backported to 2.4.

If there are no real significant-but-impossible-to-backport features in trunk, 
then the proposal itself is moot.

So let's think about it: What is currently in trunk that is a pretty 
significant improvement? Then ask if it is directly backportable. Certainly the 
effort in backporting from trunk to 2.4.x is much less than the effort in 
spinning out 2.6.x and considering all things, that should be the primary flow.

Reply via email to