Page History

Table of Contents

Introduction

The goal of Project Skara is 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 technical parts of project Skara includes several server-side tools (also called "bots") aiding contributors during code reviews. The Skara technical tooling also includes several command-line utilities for interacting with Git source code hosting providers from the command-line.

Using an external Git source code hosting provider comes with several benefits, including:

• Performance
• Community
• API

Many, if not all, external Git source code hosting services available have excellent performance, not only with regards to network performance but also when it comes to availability (uptime). The largest Git source code hosting providers also offer the OpenJDK community to tap into large, existing, communities of developers and potential contributors. An additional benefit of using an external Git source code hosting provider is getting access to an API. These APIs enables programs to interact with developers on the external Git source code hosting provider. Although not impossible to achieve today by interacting with developers over email, it is considerably harder to implement programs that interpret free form text in emails compared to using a structured API.

A significant risk when using an external source code hosting provider is to become dependent on the external source code hosting provider. The version control data itself will always be independent of source code hosting provider due to distributed architecture of Git itself. However there is a large risk in metadata such as code review comments becoming "locked in" on a particular external source code hosting provider. Mitigating this risk is a large part of Project Skara and the following work have been done so far:

• replicating all discussions in all pull requests to the OpenJDK mailing lists
• archiving all discussions in pull requests in two formats:
  • mbox (for human consumption)
  • json (for software consumption) (not implemented yet)
• notifications of all pushes to the corresponding *-changes@openjdk.java.net mailing lists to avoid dependence on any provider's RSS feeds
• using the OpenJDK census for user organization and privilege level to avoid any dependencies on external Git source code hosting provider's user organization tool

• setting up to the domain http://git.openjdk.java.net/to redirect to OpenJDK's current external source code hosting provider to avoid polluting JBS and mailing lists with direct links to an external Git source code hosting provider

Support for multiple external source code hosting provider has been a strict requirement for all server-side and client-side tooling to avoid the issue of having any tooling take on a dependency on a particular external source code hosting provider's API. All tooling is also required to work with the GitLab Community Edition (GitLab CE) which is an open source project.

Another large part of Project Skara has been to ensure that there are multiple workflows available when interacting with a Git external source code provider, including one that preservers as much as possible of the OpenJDK community's current workflow. The Skara tooling currently supports the following workflows:

• Mailing list + CLI based (similar to current workflow)
• Web browser + CLI based
• CLI only
• Text editor/IDE

All workflows can be used interchangeably and different contributors can use different workflows at the same time (even while working on the same change). The support of multiple workflows comes from the APIs provided by the external Git source control hosting provider. Examples of the work done to support multiple concurrent workflows include:

• Two-way mailing list synchronization (you can comment on pull requests via OpenJDK mailing lists)
• Automatic "RFR" emails sent to mailiing lists for newly created pull requests
• Automatically determining mailing lists to "CC" for newly created pull requests
• Automatic generation and hosting of "webrevs" (including incremental webrevs)
• Automatically run "jcheck" on every commit in every pull request
• Implement CLI tools to list, fetch, view, approve and integrate pull requests
• Implement backwards compatible ports of jcheck, webrev and defpath

Getting Started

The following sections will get you started with Git, the external Git source code hosting provider GitHub and, if you want, the Skara CLI tooling.

Git

Install Git CLI client

GNU/Linux

CentOS/Oracle Linux/RHEL

• sudo yum install git

Debian/Ubuntu

• sudo apt install git

Fedora

• sudo dnf install git

macOS

There are two ways to install Git on macOS: using Homebrew or using a direct download.

Using Homebrew

• Install Homebrew: https://brew.sh/
• brew install git

Using direct download

• Go to https://git-scm.com/download/mac

Windows

Install Git For Windows (maintained by Microsoft): https://gitforwindows.org

Initial Configuration

Git requires that you configure a username and an email. Use your full name as your username and your regular email address for the email: