Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources

[Aleksey Shipilev]

On 07/30/2018 02:41 PM, Erik Österlund wrote:
> I don't see the fascination with reinventing the source code hosting wheel again for our
> project. Perhaps there is a good point to it, but I can't currently seem to see it. 

This "fascination" is pragmatism: deal with whatever is currently available, and move to doing the
actual work. I have seen way too many attempts to fix something known good with something
potentially perfect, breaking lots of stuff in progress (I am guilty of quite a few of these
moves!). There are two very distinct starting points: OpenJDK with Git from day one, and OpenJDK
migration from Mercurial to Git -- I am not sure the benefit of the second one is not marginal.

> It seems like some are saying that with custom mercurial hacks we can achieve smaller repos competitive with git for cloning.

Well, *I* am saying that there are known ways to deal with scale in Mercurial repos, and they do
make sense in the context of large project like OpenJDK. Calling them "hacks" is the appeal to
emotion, which we need to avoid -- not the last reason for that is many Git features can be labeled
the same, in anger.

> But is it worth our focus and effort to reinvent source code hosting again because OpenJDK is so
> special, instead of just putting it on github like everybody else and have small repos natively with
> git (without hacks), good tooling, fast access with mirrors everywhere, backups, cross-repo object
> sharing, programmable bots (that can be used to e.g. check automatically if it builds on Oracle
> external platforms like PPC/S390/AArch64/Zero, so we can notice problems before they are pushed),
> etc for free? I would personally rather ride on the source code hosting experience and expertise of
> GitHub than to chase after homegrown solutions to patch the problems.

Okay, this conflates moving to Git and moving to GitHub, which are different stories.

Homegrown solutions are there for a reason: workflow control, security, reliability, performance are
in your hands -- for better or for worse. Relying on (opinionated) community infrastructure is a
risk that needs to be quantified. Doing things "like everybody else" is weird policy for large
project -- which I am reminded about every time GitHub goes down, or I see another "do not submit
PRs here" repo warning.

Let's not pretend that moving to Git/GitHub is such a no-brainer idea. This is why I am very happy
Project Skara is proposed to quantify risks and benefits of SCM infra changes.

-Aleksey