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

[Seán Coffey]

All JDK Update releases operate with the jcheck unique bug id check 
switched off. It's been that way for many years without issue.

The Update release projects enjoy a model where a stabilization forest 
can be forked off the 'main' dev forest at RDP2 milestone every 3 
months. By having the jcheck unique bug id check switched off, we've had 
maximum efficiency and flexibility in being able to move selected 
changes around from forest to forest without cost.

I believe that disabling it for feature releases will also benefit 
release management and gatekeepers for those Projects. It's very rare 
that this jcheck would catch a genuine dup bug ID issue. Switching off 
will simplify release team and gatekeeper actions for the future. The 
alternative of logging secondary bug IDs for the purpose of porting a 
bug fix from one release to another would be cumbersome and would lead 
to longer bug tails on issues.

I do welcome Phil's call for improving checks on jcheck to detect when 
backport IDs are erroneously used in changeset commits!

regards,
Sean.

On 15/02/2017 21:00, 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 
>>>
>>>