shenandoah/jdk10 and JDK 10 repository consolidation

[Roman Kennke]

> I am fine with this approach.
>
> It's nice to have this patch for when someone upstream wants to review what
> we've done.
Aleksey generates such webrevs every night:
https://builds.shipilev.net/patch-openjdk-shenandoah-jdk10/
https://builds.shipilev.net/patch-openjdk-shenandoah-jdk9/
https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/

I find this very useful.

Roman

>
>
> Christine
>
>
>
>
> On Tue, Oct 17, 2017 at 6:09 AM, Roman Kennke <rkennke at redhat.com> wrote:
>
>> Am 17.10.2017 um 12:02 schrieb Aleksey Shipilev:
>>
>>> On 09/07/2017 10:15 AM, Aleksey Shipilev wrote:
>>>
>>>> Our plan is the following:
>>>>    a) Stabilize shenandoah/jdk10
>>>> ----- we are here -----
>>>>    b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be
>>>> stable now;
>>>>    c) Stabilize shenandoah/jdk10 again
>>>>    d) Export history from shenandoah/jdk10
>>>>    e) Ask ops@ to purge shenandoah/jdk10
>>>>    f) Clone consolidated jdk10/jdk10 to shenandoah/jdk10
>>>>    g) Import history to shenandoah/jdk10
>>>>
>>>> Do you have a script that could convert changesets against "split"
>>>> repository to changesets for
>>>> "consolidated" one?
>>>>
>>>> Worst-case scenario: we squash all the changesets into one, and apply it
>>>> as patch.
>>>>
>>> I think we are at this point. My attempts to preserve 3-yr history of
>>> sh/jdk10 run into all sort of
>>> troubles, going through the maze of merges against consolidated forest.
>>>
>>> Therefore, I am tempted to bite the bullet, and import the Shenandoah
>>> sources over the monorepo with
>>> the unshuffled patch, which *loses the history*. We have the individual
>>> changesets still available
>>> in backported repositories, and we can also ask to archive current
>>> sh/jdk10 for future reference.
>>>
>>> Bulk Shenandoah patch:
>>>     http://cr.openjdk.java.net/~shade/shenandoah/monorepo/webrev.01/
>>>
>>> ...applies to today's jdk10-master copy, and seems to build and pass
>>> hotspot_gc_shenandoah fine. We
>>> can do it "for real" soon.
>>>
>>> Shenandoah folks, thoughts?
>>>
>> I am fine with this approach. Just keep the current shenandoah/jdk10,
>> maybe rename it to shenandoah/jdk10-archive or so.
>>
>> Roman
>>