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

LaMothe, Ryan R Ryan.LaMothe at
Sun Jul 29 19:21:42 UTC 2018

I also agree with a change from internally hosted Mercurial to externally hosted Github. Internally and externally, all of our work has migrated to either Gitlab/Stash or Github, respectively. That includes our Subversion and Mercurial code bases. Some of the primary benefits of this migration has been increased tooling support, increased vendor support and significantly easier patch/feature/etc. submissions by staff. For example, staff can now simply fork a git repo, apply their changes and submit pull requests via JIRA. Reviews of pull requests can be performed in multiple different CLI or GUI tool suites. No more DIFF files attached to issue tickets! Additional data point, while git itself (at least the command line) has been more complicated to use and understand than svn, requiring additional training and testing, the move from mercurial to git was relatively straightforward.

Ryan LaMothe

On 7/26/18, 9:17 PM, "discuss on behalf of joe darcy" <discuss-bounces at on behalf of joe.darcy at> wrote:

    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 
    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.

More information about the discuss mailing list