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

Stephen Colebourne scolebourne at
Sat Jul 28 06:16:20 UTC 2018

I support the creation of this project. I think the list of
tasks/considerations is reasonable, although I believe that git is the
only realistic alternative.

As a data point, I've used git for everything I do for years. I now
pretty much refuse to use anything else. I disliked it strongly
initially, but now find it invaluable - there is a learning curve, and
as a developer you have to invest time to get over that.

Personally, I found Mercurial almost unusable when I had to use it for
JSR-310. I have had no desire to fight Mercurial again since JSR-310
was complete. As such a number of bugs have lingered that I might
otherwise have tackled (as only Oracle employees are tackling them).
Given this, I strongly suspect that use of git (preferably via GitHub)
would greatly increase my ability to contribute.


On 27 July 2018 at 04:42, joe darcy <joe.darcy at> wrote:
> Hello,
> The source code management (SCM) system of a software project is a
> fundamental piece of its infrastructure and workflows. Starting in February
> 2008, the source code of different JDK releases and supporting projects has
> been hosted in Mercurial repositories under
> Code reviews of JDK changes are typically conducted as discussions in
> mailing lists over small patches sent to one or more lists or over webrevs
> hosted on Since 2008, many open source projects have
> successfully adopted more efficient SCM and review tooling, in some cases
> provided by third parties.
> In order to help OpenJDK contributors be more productive, both seasoned
> committers and relative newcomers, the Skara project proposes to investigate
> alternative SCM and code review options for the JDK source code, including
> options based upon Git rather than Mercurial, and including options hosted
> by third parties.
> The Skara project intends to build prototypes of hosting the JDK 12 sources
> under different providers.
> The evaluation criteria to consider include but are not limited to:
>     * Performance: time for clone operations from master repos, time of
> local operations, etc.
>     * Space efficiency
>     * Usability in different geographies
>     * Support for common development environments such as Linux, Mac, and
> Windows
>     * Able to easily host the entire history of the JDK and the projected
> growth of its history over the next decade
>     * Support for general JDK code review practices
>     * Programmatic APIs to enable process assistance and automation of
> review and processes
> If one or more prototypes indicate a different SCM arrangement offers
> substantial improvements over the current situation, the Skara project will
> shepherd a JEP to change the SCM for the JDK.
> I propose to lead the project with the initial reviewers including but not
> limited to Tim Bell (tbell), Erik Duveblad (ehelin), Erik Joelsson (erikj),
> Tiep Vo (tiep), Tony Squier (squierts), and Robin Westberg (rwestberg).
> We suggest the build group sponsor this work.
> Changing the bug tracking system is out of scope for this project and is
> *not* under consideration.
> Comments?
> Cheers,
> -Joe

More information about the discuss mailing list