How To Solve a Problem Like Shenandoah 8u

[Roman Kennke]

Hi Andrew,

>>> Others who do more frequent backports than me (Aleksey maybe?) might
>>> have more insights.?
>>
>> Our backport tracking machinery parses the changesets in that HG repo. That's the only option for
>> tracking, because 8u Shenandoah backports are not tracked in JBS. I suspect it would be fine to keep
>> the read-only snapshot of old Mercurial repo, so that backports-monitor can still read it.
>>
>> FWIW, we did the similar history-losing-squash commit when moving sh/jdk9 -> sh/jdk10 for the
>> monorepo migration, and that was not very painful.
>>
>> -- 
>> Thanks,
>> -Aleksey
>>
> 
> So we now have 8u hg monorepos:
> 
> https://hg.openjdk.java.net/jdk8u/monojdk8u/
> https://hg.openjdk.java.net/jdk8u/monojdk8u-dev/
> 
> and live read-only git mirrors:
> 
> https://github.com/openjdk/jdk8u
> https://github.com/openjdk/jdk8u-dev

Nice!

> What I would suggest for aarch64/shenandoah-jdk8u going forward is:
> 
> 1. We merge the 8u322 build promotions as usual, so we are in sync with the new repositories
> 2. Fork the jdk8u git repository to sh/jdk8u and apply the Shenandoah changes as one patch on top
> 3. Future merges to the new git repo are from the read-only 8u git mirror (which will become live next year)

This sounds reasonable to me.

> I don't see a need to temporarily have a Shenandoah hg monorepo as
> there are few commits directly to these repositories. It will actually
> be a good test of the 8u git repo to use it before it goes live for
> development.

Yes, that makes sense.

> I guess you'll also want a sh/jdk8u-dev git repository as an equivalent
> of the current sh/jdk8u for working on 8u backports.

Yeah, that makes sense, too, IMO.

Thank you!
Roman