shenandoah/jdk10 and JDK 10 repository consolidation

[Christine Flood]

I am fine with this approach.

It's nice to have this patch for when someone upstream wants to review what
we've done.


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
>