Looking ahead: proposed Hg forest consolidation for JDK 10

[joe darcy]

On 10/14/2016 10:03 AM, Brian Goetz wrote:
>
>> 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.
>

Another forward-looking consideration is what kinds of changes do we 
want to encourage or make easier in evolving the JDK? In absolute 
percentages, cross-repository changes are relatively uncommon compared 
to the total number of bug fixes, in part because of the complications 
of doing them. However, those cross-repository fixes also have the 
potential to be very high-leverage changes.

Multiple JDK 9 features large and small have made such repo-crossing 
changes, ranging from Jigsaw on the high-end to smaller features such as 
using indify for string concatenation (JEP 280) and VarHandles (JEP 
193). I think we should expect and encourage more features like this in 
the future. The logistics for some other relatively simple changes like 
adding a new javac warning would be greatly eased by having a unified 
repository.

Cheers,

-Joe