How to handle future backports from JDK 10 into JDK 9? (original) (raw)

Phil Race philip.race at oracle.com
Mon Feb 13 23:31:59 UTC 2017

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

More information about the jdk10-dev mailing list