Looking ahead: proposed Hg forest consolidation for JDK 10

[Brian Goetz]

> Conversely, I think it is reasonable for engineers making changes to 
> the JDK to be wiling to offer some flexibility in adjusting 
> established worksflows optimized for the split repositories to 
> accommodate the sort of infrastructure changes being proposed here for 
> a consolidated one.

Let me amplify this: OpenJDK developers are not the only stakeholders 
here.   By aligning more with the way the rest of the world develops -- 
all code in one linearized, transactionally updated repo -- it increases 
the feasibility / reduces the cost of tools like 'bisect' to determine 
where a fault was introduced.  This reduces SQE costs and increases 
product quality -- something we all have a stake in.  David Lloyd has 
pointed up other tooling-related benefits, such as making it easier to 
maintain a git mirror.

Most of the objections raised so far have been "(I think they will) make 
my life harder."  Fair enough; people should be their own advocates.  
But let's not forget the significant benefits that accrue to *everyone* 
as a result, and keep those in mind when judging the pros and cons.