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

[Seán Coffey]

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