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

Volker Simonis volker.simonis at gmail.com
Fri Feb 17 08:21:24 UTC 2017

On Thu, Feb 16, 2017 at 11:11 PM, David Holmes <david.holmes at oracle.com> wrote:

Hi Joe,

On 17/02/2017 6:01 AM, joe darcy wrote:

Hi Vladimir, If the HotSpot team is concerned matching bug id and summaries, I suggest using a wrapper script around jprt or hg push that does that check. I know various individuals have written such scripts for their own use; probably a case where we could do a better job sharing small tools. That's solving the problem in the wrong place in my opinion. In my estimation, using back port bug ids for pushes would be more prone to errors/typos than continuing the long-standing policy of using the main bug id in such cases. That wasn't the suggestion. The suggestion was to create a new bug eg "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of creating an actual backport-issue using the original main bug id.

I totally agree with David and would strongly support his suggestion. We could introduce a new line in the change comment like "Backport-of: " so we can easily find and identify such changes. And after all, there hopefully shouldn't be to many of them.

Cheers, David

Cheers, -Joe

On 2/15/2017 1:00 PM, Vladimir Kozlov wrote: We discussed this in Hotspot and support David's opinion here. We should not relax jcheck and we can use backport type different bug id as he suggested. Regards, Vladimir On 2/13/17 6:15 PM, David Holmes wrote:

On 14/02/2017 8:54 AM, 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.

I think that check has helped avoid pushes with mis-typed bug numbers. Unless we have a stronger "does this bug id match the bug synopsis" check I would not want to see this bug id check relaxed. I would not expect there to be many cases where something is deferred to 10, fixed, and then re-considered for 9. But if that does happen I think the simplest thing may be to do the backport under a new bug id (as already happens at time in the update releases when the backport is not clean). Thanks, David ----- 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