JDK 10 forests open for bug fixes and small enhancements

[Tobias Hartmann]

On 26.01.2017 13:18, David Holmes wrote:
> 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. ??

Yes but that happened because these failures do not always show up. For example, JDK-8173391 and also JDK-8172010 you've mentioned on hotspot-dev.

Best regards,
Tobias

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