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

[David Holmes]

On 20/02/2017 7:11 PM, Seán Coffey wrote:
> On 18/02/2017 03:14, David Holmes wrote:
>
>> Creating a new bug for a "backport" is already existing practice for
>> the update releases, so this isn't something radically new.
> I don't believe above to be accurate. An engineer rarely has to create a
> backport bug ID. For the majority of cases, it's automatically handled
> by hgupdater tooling and no one has to ever reference the backport ID.

I think there is a misunderstanding. What I am talking about is when a 
specific issue is created (of type bug or rfe) to handle the backporting 
of some fix or enhancement, when the use of a direct "backport" of the 
original fix/ref is not possible for some reason.

The bug database is littered with such issues, for example:

https://bugs.openjdk.java.net/browse/JDK-8038440
https://bugs.openjdk.java.net/browse/JDK-8052313

and there are many, many examples.

David
-----

> This is especially true for the automated sync ups that occur between
> forests. In the scenario where duplicate bug IDs are not allowed, a
> gatekeeper has to halt the sync and delay integration schedule in the
> event where duplicate bug IDs cross between different forests.
>
> The golden rule today is to use the same master bug ID for pushing the
> same fix across all JDK forests.
>
> Using a different bug ID to push the same fix would just add unnecessary
> confusion. It would also cause issue for automated scripts checking for
> bug fixes in various JDK forests. We'd be in a state of "did we use this
> bug ID or that bug ID to push the fix?". Rare or not, it would just
> break tooling and queries. It would be something radically new.
>
> regards,
> Sean.
>
>> On 18/02/2017 4:20 AM, Joseph D. Darcy wrote:
>>> Hi David,
>>>
>>> On 2/16/2017 2:11 PM, David Holmes 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.
>>>
>>> The designers of jcheck made an architectural decision to not have
>>> jcheck depend on or use the bug database.
>>>
>>> Without revisiting that design decision, a wrapper script of some sort
>>> is a way the check in question could be implemented today.
>>
>> Perhaps that decision should be revisited - was it the same bug
>> database when the decision was made? In any case perhaps we can
>> distinguish between jcheck running on the hg servers versus jcheck
>> running at hg commit time on the user's machine? After all the latter
>> is no different from the ends users perspective, but it avoids the
>> need for duplication of effort to create wrappers, and for people to
>> have to opt-in to using those wrappers.
>>
>>>>
>>>>> 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.
>>>>
>>>
>>> That approach, while workable, seems to me to work across purposes with
>>> the bug tracking system. The most natural way to represent a backport is
>>> a backport issue.
>>
>> Yes that is the "most natural" way but can cause problems - hence this
>> conversation. Creating a new bug for a "backport" is already existing
>> practice for the update releases, so this isn't something radically new.
>>
>> And, again, we expect this to be a very rare occurrence.
>>
>> Cheers,
>> David
>>
>>> -Joe
>