Project Skara: Tooling is now open source and available on GitHub

It has been almost a year since the JDK team launched the discussion in order to investigate alternatives for JDK source code management and our readers made their opinion very clear!

According to the poll we launched last year, the vast majority of the respondents believes that the most beneficial alternative SCM and code review for the JDK source code is Git.

Results speak for themselves:

Today, we revisit the discussion as the JDK team takes the next step and makes the tooling for Project Skara available on GitHub.

In the Skara GitHub repo you can find the tooling for working with OpenJDK projects and their repositories.

The CLI tools that are available as part of this repository are:

• git-jcheck – a backwards compatible Git port of jcheck
• git-webrev – a backwards compatible Git port of webrev
• git-defpath – a backwards compatible Git port of defpath
• git-fork – fork a project on an external Git source code hosting provider to your personal space and optionally clone it
• git-pr – interact with pull requests for a project on an external Git source code hosting provider
• git-info – show OpenJDK information about commits, e.g. issue links, authors, contributors, etc.
• git-token – interact with a Git credential manager for handling personal access tokens
• git-translate – translate between Mercurial and Git hashes
• git-Skara – learn about and update the Skara CLI tools

You can also find CLI tools available for importing OpenJDK Mercurial repositories into Git repositories and vice versa:

• git-openjdk-import
• git-verify-import
• hg-openjdk-import

Head over to the OpenJDK Project Skara repo on GitHub for all the details.

The discussion so far

It has already been three weeks since the JDK team launched the discussion in order to investigate alternatives for JDK source code management and the community seems to have made up its mind. Or has it?

On the one hand, the results of the JAXenter poll seem to be pretty clear. Git wins. That’s it. No further explanation needed.

On the other hand, the three interviews we had with Java experts paint a not-so-crystal-clear picture. Let me explain.

In the first interview, we talked to Java Champion and JavaOne Rock Star speaker Stephen Colebourne, who seems to be rather enthusiastic about the prospect of migrating JDK source code management to Git.

From my perspective, I think using Git instead of Mercurial is a great idea. I can’t see any case to move to any other SCM.

Stephen Colebourne

However, for our second interview, we caught up with OpenJDK Author Patrick Reinhart who based his view mostly on the popularity of Git as opposed to Mercurial.

For new contributors, Git seems to be more tool-friendly than Mercurial is at the moment.

Patrick Reinhart

For our last interview, that went online just yesterday, we talked to OpenJDK committer Thomas Stüfe, who seems to have a rather conservative opinion on the matter.

 I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.

Thomas Stüfe

The interview responses seem to be in total progression here: Git is great! – It makes sense, I guess. – I see no reason to change.

You may think that we did that on purpose but, trust me, we didn’t!

Is this mini-interview series an accurate representation of what the community thinks? Or are the poll results the definite response to the question: What is best alternative SCM and code review for the JDK?

How it all started

Project Skara was launched by the JDK team in order to investigate alternatives for JDK source code management, that’s been using Mercurial repositories since 2008.

The reason behind the initiation of this project was the idea to help OpenJDK contributors be more productive. In his mail, JDK developer and OpenJDK reviewer Joe Darcy wrote:

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.

According to the same source, “the Skara project intends to build prototypes of hosting the JDK 12 sources under different providers”.

Joe also listed evaluation criteria that are to be considered. He urged, however, the contributors not to limit themselves to these criteria which include:

• 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

Joe also made it clear that “changing the bug tracking system is out of scope for this project and is not under consideration”.

SEE ALSO: “Asity is the most suitable toolkit to support server-side Java”

That wrapped up the nature of the project and the proposed changes. Let’s head over to the discussion.

It’s the “old vs. new” battle

The opinions of the participants to the discuss mailing list seem to have been split into two groups: There are those who find a potential transition from Mercurial to Git to be more convenient, as well as those who hardly see the benefits of such a transition.

Both groups, however, seem to agree on one thing: If there are, indeed, any benefits to reap from a transition from Mercurial to Git, that can only happen if the processes for managing OpenJDK are also changed.

According to the responses in the discuss mailing list, contributing can be tricky without being hired into the JVM development team. But the choice of technology is not the biggest barrier to entry, according to one of the responses. “What we would need is a change of process if we are going to open up OpenJDK”.

What’s your take on the proposals made in Project Skara?

The post Project Skara: Tooling is now open source and available on GitHub appeared first on JAXenter.