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

[Joseph D. Darcy]

Hello,

Last call for objections to disabling the unique bug id check in JDK 10.

Thanks,

-Joe

On 3/27/2017 10:11 AM, joe darcy wrote:
> Hello David and others,
>
> Returning to this topic, I concede there are exceptional cases where 
> backporting some functionality under a different bug id may be 
> reasonable. However, I don't think such rare cases should drive larger 
> decisions of handling forward and backports in 9 and 10 and whether or 
> not the duplicate bug id check should be disabled in JDK 10.
>
> While the bug id check does prevent the error of accidentally reusing 
> a bug id, it does not prevent many other classes of errors around bug 
> ids, such as swapped digit typos. (Sharing of scripts to do such 
> checks pre-push welcome.) Additionally, the duplicate bug id check 
> causes complications, including the topic under discussion now, as 
> well as for the possible repository consolidation. That check has been 
> disabled in the update releases for years without problems.
>
> Therefore, on the whole, I think it would be a net benefit to disable 
> the duplicate bug id check for JDK 10 too.
>
> Cheers,
>
> -Joe
>
>
> On 2/21/2017 7:05 PM, David Holmes wrote:
>> Hi Joe,
>>
>> From my own observation/experience the "why" we would create a new 
>> bug to "backport" something is when the something is not neatly 
>> packaged and obtainable through direct backports of specific issues. 
>> Take an example of an issue that is fixed but is buggy and has quite 
>> a lengthy bugtail - once it is reliable you want to backport it to an 
>> earlier release. Do you backport each individual bug (some of which 
>> may not even apply to the earlier release) or do you backport the 
>> resulting functionality that was finally obtained? There are pros and 
>> cons to both approaches - neither is clean nor ideal. Such is life.
>>
>> Cheers,
>> David
>> -----

[snip]