Brent Roman wrote:
> Charlie,
> 
> Much of the advantage I saw in moving 1.8.6 maintenance away from core
> was to allow core to introduce new features and backports into the 1.8
> series without
> any fear that these might destabilize 1.8.6.

1_8_6 is already its own branch and only gets merged as the maintainer 
deems appropriate. No *new* work goes into 1_8_6, and all merged come 
from other branches (ruby-core folks, correct me if I'm wrong here).

> How can that work if the external maintainer of 1.8.6 is forced to take
> every
> patch core submits on the 1.8 branch?  

Nobody ever said that...just that patches must come down through the 
other branches before being merged to 1.8.6 *if appropriate*. There's no 
forcing involved.

> Would not a fork be appropriate?

DEFINITELY not. 1.8.6 is still part of MRI, it just has a new maintainer 
managing patches.

> If it did not fork, would the 1.8.6 maintainer be committing their changes
> to HEAD,
> possibility conflicting with core's work on 1.8.7+ or even 1.9?

No changes should get into 1.8.6 that don't filter down through other 
1.8 versions at the very least. 1.8.6 should not diverge with fixes or 
features that the other 1.8 versions don't receive.

- Charlie