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

[Stephen Colebourne]

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.

thanks
Stephen


On 27 July 2018 at 04:42, joe darcy <joe.darcy at oracle.com> 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 http://hg.openjdk.java.net/.
> 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 cr.openjdk.java.net. 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
>