JDK 10 forests open for bug fixes and small enhancements

[David Holmes]

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.

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
>