JDK 10 forests open for bug fixes and small enhancements

[David Holmes]

Hi Tobias,

On 26/01/2017 10:13 PM, Tobias Hartmann wrote:
> 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?

I don't know, that's what I am asking. :) We need the missing fixes to 
propagate through before we can actual submit via JPRT.

But I would not have expected anything that causes a JPRT failure to 
have escaped from jdk9/hs to jdk9/dev. ??

Thanks,
David

> 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
>>>