New candidate JEP: 357: Migrate from Mercurial to Git

[Joe Darcy]

Catching up on email...

On 7/16/2019 3:22 AM, Emmanuel Bourg wrote:
> Le 16/07/2019 à 11:49, Mario Torre a écrit :
>
>> and from what I see tooling support and size
>> of the download are the two only reason to use git
> One obvious benefit that is worth mentioning in the JEP I think is that
> Git is significantly more popular than Mercurial, and using what becomes
> a standard tool lowers the barrier of entry for new contributors. A mere
> read-only Git mirror doesn't help unifying the community around a common
> set of tools and workflows.

 From one set of data points, the 2015 and 2018 stackoverflow surveys 
about version control, a table showing the reported usage of git, 
Mercurial, and no version control (other options omitted):



	2015
	2018
git
	69.3%
	87.2%
Mercurial
	7.9%
	3.6%
no version control
	9.3%
	4.8%

Good to see fewer respondents not using version control in 2018 compared 
to 2015, but in both cases not using version control was more common 
than using Mercurial. Between 2015 and 2018 all of Mercurial, 
Subversion, and Team Foundation saw lower usage in this survey in 
contrast with Git's gains. (The 2019 survey does not cover version 
control systems.)

As time goes on, I don't think it is advantageous for OpenJDK to be one 
of the diminishing number of open source projects using Mercurial. 
Within the last few years, another long-time Mercurial-using project, 
Python, moved from Mercurial to git 
(https://www.python.org/dev/peps/pep-0512/).

There are many aspects of working on OpenJDK that are challenging or 
different compared to most other projects (strict code review, long 
lifetime of the sources, etc.) and using what is becoming more and more 
a niche tool for foundational infrastructure becomes less compelling 
unless it offers fundamental architectural advantages. However, there 
isn't that kind of distinction between Mercurial and Git in Mercurial's 
favor. There are technical differences between Git and Mercurial of 
course, as discussed elsewhere on this thread, but none of the magnitude 
of, for example, centralized vs distributed SCM. The existence of 
converters between Git and Mercurial demonstrates a kind of rough 
equivalence, even with significant differences in encoding size, etc.

While I myself have worked on OpenJDK for my years, I would understand 
if someone coming to the project new would find its choice of Mercurial 
unfamiliar and off-putting. I don't think use of Mercurial should be an 
intrinsic or distinguishing part of OpenJDK development, as opposed to, 
say, code review practices.

A goal of the Skara tooling is to allow existing JDK development 
practices to continue while also offering a more contemporary 
alternative. The Skara tooling is now used to develop the Skara code 
itself on github, https://github.com/openjdk/skara/. A developer can 
view the text of a proposed change in either github/gitlab or a webrev 
and also follow the review discussion on github/gitlab or on a mailing 
list. One particular example, a github PR (pull request)

     https://github.com/openjdk/skara/pull/12

triggers a bot to generate a webrev

     https://openjdk.github.io/cr/skara/12/webrev.00

and initiate a corresponding thread on the skara-dev mailing list:

https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000119.html

Cheers,

-Joe

[1] https://insights.stackoverflow.com/survey/2015#tech-sourcecontrol

[2] https://insights.stackoverflow.com/survey/2018/#work-_-version-control