Proposal to revise forest graph and integration practices for JDK 9

[David DeHaven]

>>> So, I'd like to suggest that jdk9/dev replaces the equivalent of jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go.
>> 
>> For the open components, that is essentially the proposal. Deploy and install are closed and have different testing requirements from other code so would likely remain separate.
> 
> Cool. Fwiw, I only mentioned deploy in there because there is a jdk8/deploy 'scratch' forest on hg.openjdk.java.net which presumably just complements a closed one to make integrations simpler. 
> 
> In practice, I don't think that it's very useful to have such setups where a closed forest has an OpenJDK counterpart and no actual development is done in OpenJDK - at best it leads to confusion, at worst it leads to spurious changes that have to be done because of the poor, established repository & forest layout, rather then because they make technical sense.

(speaking as a member of the deploy team...)

A majority of this particular discussion needs to be done offline, but I'm not entirely convinced that we need to continue to have our own OpenJDK forest.

The several times I've needed changes outside of deploy I've had to go through a different workspace (such as awt or tl) which means the corresponding deploy changes have to wait at least one integration cycle for those changes to trickle over to our workspace (then I have to pester someone to synchronize our OpenJDK forest with master), lest our builds be broken by half-implemented changes. On the flip side, we've had issues where changes or improvements were made in jdk or hotspot and we don't see them for weeks or months because they're not synced up in a timely fashion. Any way to improve that would get my vote.

-DrD-