How to handle future backports from JDK 10 into JDK 9?

[Kevin Rushforth]

 > Therefore, I think the better option is to also disable the unique 
bug id check for the JDK 10 forests to allow easier syncing between 9 
and 10.

This seems good to me. We haven't noticed a big problem with this in the 
JDK update releases where the unique Bug ID check is turned off. We also 
haven't seen problems in JavaFX (where we currently don't have jcheck 
enabled at all, but are working towards it, with the unique bug ID check 
disabled).

I note that disabling the unique bug ID check will also help with the 
bug ID collision that will otherwise occur in the proposed repo 
consolidation, and which would otherwise need a solution.

-- Kevin


joe darcy wrote:
> Hello,
>
> An open question in Mark's announcement that the JDK 10 forests are 
> open [1] concerned how to manage backports from JDK 10 to JDK 9:
>
> "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 ..."
>
> As a reminder, the overall model (for now) is that all fixes from JDK 
> 9 will be synced into JDK 10; the first sync of several hundred bugs 
> happened recently and went smoothly. [2]
>
> The potentially problematic situation would occur if
>
> * Bug JDK-8181818 is first fixed in JDK 10
> * Bug JDK-8181818 is then backported to JDK 9
> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug 
> id JDK-8181818 even though the code may be identical
>
> One way to avoid this problem would be to do the push to JDK 9 under 
> an explicit backport bug id rather than the main bug id JDK-8181818. 
> This approach has a number of drawback. First, long-standing social 
> convention has been to "always use the main bug id." Second, tooling 
> like Hg updater has been written on the assumption that the main bug 
> id will always be used to conceptually refer to an issue.
>
> The purpose of the jcheck unique bug id check stems from preventing 
> sloppy bug handling where multiple changesets partially and 
> incrementally address a bug and it is not clear whether or not an 
> issue is fully fixed or not.
>
> However, even without programmatic enforcement of unique bug id, I 
> don't think JDK development practices would devolve in that way. As 
> supporting evidence, the unique bug id check is disabled in the 8 
> update forests to allow fixes from multiple releases to come back 
> together in the always-open forest and the pathologies around partial 
> fixes have not occurred.
>
> Therefore, I think the better option is to also disable the unique bug 
> id check for the JDK 10 forests to allow easier syncing between 9 and 10.
>
> Comments?
>
> Cheers,
>
> -Joe
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html
>
> [2] 
> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html 
>
>