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

[Phil Race]

 > on the assumption that existing social conventions adequately
 > protect us from the pathological scenarios that are prevented by this 
test.

Well .. maybe .. it could also be that we got stopped at the commit 
stage from
making an mistake and have learned this convention through the enforcement.
Future developers not exposed to it may not learn the lesson so well and 
would
also not benefit from the enforcement.
As is the case for "don't use the backport ID when backporting", which 
is not
enforced anywhere and I've made that mistake a few times as a result.

-phil.

On 02/13/2017 02:54 PM, 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
>