RFR: Bulk backports jdk12 -> sh/jdk11

[Roman Kennke]

Am 12. März 2019 05:32:06 MEZ schrieb Andrew John Hughes <gnu.andrew at redhat.com>:
>On 11/03/2019 20:45, Aleksey Shipilev wrote:
>> On 3/11/19 9:29 PM, Roman Kennke wrote:
>>> This backports all relevant Shenandoah changes (I hope) from
>jdk-updates/jdk12u to shenandoah/jdk11.
>>>
>>> They all applied mostly clean and trivial. Builds and tests look
>good.
>>>
>>> List of changes:
>>>
>http://cr.openjdk.java.net/~rkennke/upstream-jdk11-merge-2019-03-11/changes.txt
>>>
>>> Full webrev:
>>>
>http://cr.openjdk.java.net/~rkennke/upstream-jdk11-merge-2019-03-11/webrev.00/
>> 
>> Looks good to me. Thanks!
>> 
>> Hold on for a minute, though.
>> 
>> Andrew Hughes, notice the synopsis format for the changes:
>>  [backport] $BUGID $SYNOPSIS
>> 
>> This is almost the same as we did over the years for
>Shenandoah-specific backports, but now it also
>> mentions $BUGID, because Shenandoah is finally upstream. We would
>like to separate backports that
>> are coming to our downstream version of Shenandoah versus the
>upstream changes (especially those
>> coming via 11u updates), therefore Shenandoah-specific backports done
>by Shenandoah devs start with
>> "[backport]". This would also avoid these backports to be
>accidentally matched by jcheck and/or
>> hgupdater.
>> 
>> Does it make sense to you?
>> 
>> -Aleksey
>> 
>
>That makes sense to me.
>
>My concern is that this is *only* bugs that don't make sense for
>upstream 8u or 11u. Anything that can be applied upstream should be and
>then integrated into the Shenandoah repositories with a merge. Now
>we're
>handling the tagging/release process there, I don't expect that to have
>as many delays as in the past.

Yes, that is the plan. Only Shenandoah backports would come this way because there is no Shenandoah in 8 or 11.

Thanks, Roman

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.