JDK 10 forests open for bug fixes and small enhancements

[Tobias Hartmann]

Hi David,

On 26.01.2017 13:06, David Holmes wrote:
> Hi Mark,
> 
> Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes.

Isn't this just because those changes are not yet in jdk9/dev but only in hs and jdk10 is synced with jdk9/dev?

Best regards,
Tobias

> 
> Thanks,
> David
> 
> On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote:
>> The Mercurial forests for JDK 10 are now available:
>>
>>   http://hg.openjdk.java.net/jdk10/jdk10    --  Master + dev (combined)
>>   http://hg.openjdk.java.net/jdk10/hs       --  HotSpot
>>   http://hg.openjdk.java.net/jdk10/sandbox  --  Sandbox
>>   http://hg.openjdk.java.net/jdk10/client   --  Client libraries
>>
>> Corresponding -changes mailing lists have also been created.
>>
>> The main differences from the forests for JDK 9 are that there are fewer
>> of them, and that the "dev" and master forests have been combined.  Most
>> committers should push directly into jdk10/jdk10 except when working on
>> HotSpot, a branch in the sandbox forest, or the client libraries.
>>
>> As of today these forests are open for bug fixes and small enhancements.
>>
>> Many committers will continue to focus mainly on JDK 9 for the next few
>> months so, for now, we'll semi-automatically pull changes from JDK 9 and
>> merge them into JDK 10.  This means that if you make a change in JDK 9
>> then you needn't do any extra work to get it into JDK 10, though if a
>> merge conflict arises then you might be asked to help resolve it.
>>
>> For work that's new in JDK 10, please try to keep destabilizing changes
>> to a minimum, for now, in order to reduce the overhead of the continuous
>> merges from JDK 9.  If you want to work on a destabilizing change for
>> JDK 10 then consider starting that work in a sandbox branch.
>>
>> Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as
>> usual, to target significant features.
>>
>> The JDK 10 forests have the same structure as the JDK 9 forests.  The
>> repository consolidation proposed in JEP 296 [1] might be implemented
>> later in the release.
>>
>> In the (hopefully infrequent) event that a change in JDK 10 needs to be
>> back-ported to JDK 9 we'll have to figure out how to handle the duplicate
>> bug ids that will arise when a back-ported change is later merged forward
>> into JDK 10.  One solution may just be to disable the unique bug-id test
>> in jcheck, on the assumption that existing social conventions adequately
>> protect us from the pathological scenarios that are prevented by this
>> test.  Thoughts welcome ...
>>
>> - Mark
>>
>>
>> [1] http://openjdk.java.net/jeps/296
>> [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>>