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

[David Holmes]

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.

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
>>>>
>>>>
>