[External] : Re: Switch jdk8u development to Git/Skara

[erik.joelsson at oracle.com]

Hello Andrew,

Thank you for your detailed reply!

On 2021-09-30 19:25, Andrew Hughes wrote:
> Hi. Sorry for the delayed reply, but we needed some time to think
> this over in detail.
No worries.
> I'd still consider the 11u move in progress, as it's not yet
> completed a release from the new repository. That's the stage
> that particularly concerns me and I'll be keeping an eye on.
Understood.
> The possibility of a two-phase approach to this has allayed a lot of my
> fears about the possibility of such a transition. Following the well-trodden
> path used by the main JDK repositories, and the greater time period to
> adapt to the transition, would ease things a lot.
>
> Having discussed this at length with Severin, I propose the following timetable:
>
> 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development)
>
> * Convert 8u & 8u-dev to Mercurial mono repositories.
> Given they should be identical at this point, it should be possible to
> do one conversion of 8u, provide copies at both 8u and 8u-dev, and
> then let each copy diverge.
>
> * Create live read-only mirrors of 8u & 8u-dev in git
>
> 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development)
>
> * 8u-dev development switches to Git & Skara, with the previous read-only
> git mirror being used directly.
> * 8u remains on Mercurial for the release of 8u332.  8u can be synced
> to 8u-dev from the 8u git mirror.
>
> 3. April 2022 (Release of 8u332)
>
> * 8u git is used directly for promotions of 8u342.
>
> I think this provides the best balance of risk, while also allowing 8u
> to be consumed from git within the next few months.
I think this plan looks reasonable, but I will need to check internally 
before I can give a final go ahead. Could you narrow down the potential 
cut over windows to date ranges?
> The most demand I'm seeing for 8u to be in git is from downstream
> users, who expect it to be on github with the rest, while the most
> change is required from developers, who have to adapt to the markedly
> different process used by Skara.  The above allows an additional cycle
> for developers to adapt to this change, see the live git mirrors in
> operation and perhaps experiment with development in later JDK trees.
> Meanwhile, downstream users should be able to start working with
> 8u in git from December.
>
> Please let us know if the above seems feasible.  My understanding
> is that the majority of work will be at the end of November,
> and the second and third changes should just be a matter of making
> it possible to commit to the git repositories.

Yes, the consolidation is the trickiest part with the most amount of 
unknowns that could potentially delay things. I do believe I have it 
under control however. You can look at the current prototype here:

https://hg.openjdk.java.net/jdk8u/consol-proto/

> A couple of additional questions:
>
> 1. Would the consolidation to a monorepo take place on top of
> the existing root repository or be an entirely new Mercurial
> repository? I've been trying to recall from the jdk10 transition,
> but can't remember. Either way, the change for developers should
> just be a one-time switch to the repository and the process
> of submitting patches remains exactly the same as it is now,
> except everything is from the one repository.
No, it's a new repository. In the case of the OpenJDK 8u consolidation, 
it will be based on the existing JDK 10 consolidated repository and 
share history up until jdk8-b120, where the history started to diverge 
in the original repositories. The change for developers should be 
minimal as you say. The guarantee we give is that each promotion tag is 
equivalent between the monorepo and the forest.
> 2. Is the consolidated repository expected to be identical
> to a fully-checked out copy of the forest (i.e. the root
> repository with each subrepo as a top-level subdirectory).
> I know some files moved with jdk10, but I think we'd want
> everything to stay the same with 8u.
Yes, the file layout is identical. We have no plans to rearrange things 
for 8u. You may want to do some cleanup afterwards, like removing the 
hgforest.sh/get_source.sh scripts that are no longer useful and remove 
the no longer used .hgtags files from old nested repo directories.
> 3. As mentioned in another reply, could Skara's backport
> command be adapted to "shuffle" the paths to fit the
> 8u layout? This may be quite tricky as currently it
> requires both the 10u->9u conversion and the 9u->8u
> conversion, but without this, the backport command
> is effectively unusable and they all would have to
> be performed manually.
I can see this being a very useful feature, but also a non trivial 
effort to implement. I can't say at this time if I would personally be 
able to allocate time for this.
> 4. Could Skara be adapted to enforce the jdk8u-fix-yes /
> jdk8u-critical-yes JIRA labels so the change can't be pushed until it
> has been approved?

This sounds like a rather simple feature in comparison. Please file an 
enhancement request for SKARA.

/Erik