New candidate JEP: 369: Migrate to GitHub

Johan Vos johan at
Sat Nov 16 18:28:26 UTC 2019

I've had the privilege to work with the Skara tools in both the OpenJDK
Mobile and the OpenJFX projects.
Having read most of the comments in this thread, there are a few things
that I would like to add.

The quality of a project like OpenJDK highly depends on the committers. If
we want to maintain the current high quality, it is important that the
current committers, who are responsible for this quality, are ok with
changes in the process. My observation during the OpenJDK Committers'
Workshops is that most committers are ok. However, it's very important to
take into account the critics from committers who do not like this JEP.

>From what I've read so far, and from my experience dealing with the Skara
team, I personally don't see real showstoppers.
One of the things I really like about the Skara approach is the automatic
creation of an RFR mail and the creation of a webrev. That already saved me
lots of time in the OpenJFX project, time that I could contribute to write
code or review PR's. More automation, less chances for typo's are a great
thing. I like the guidelines of the bot and the flow is very intuitive. I
can choose to work via the web interface or via the CLI.

Yes, the GitHub web interface is by no means a 100% match of the email
approach, and I don't hide it that I'm not a big fan of the
"Web-everywhere-for-everything" approach, on the contrary.
However, comparing other github projects I work on with the Skara-based
projects I work on, I really like the Skara approach. Thanks to the Skara
tools, the dependency on web-based control flow is much lower. And most
important, the Skara tools are open source and can be discussed and

I honestly don't know what the best approach is for discussing PR's. As
stated in other replies, the conversation-tab in the GitHub PR's has its
limitations, but it has also stated correctly that email discussions have
limitations and can create confusion as well.

Looking at the alternatives in the JEP, there is nothing that comes close
to the current proposal. While I don't think there will immediately be a
large number of high-quality new contributors simply because of the move to
github, I am convinced the barrier becomes lower. Moreover, the github
approach makes it easier for developers who depend on the JDK to examine
the code if needed. I often run into issues with third party software, and
when I can easily find the code on github, it makes it much easier to
understand, appreciate, or even help. Having to browse through the hg web
interface, or download the whole JDK project, is not really inviting.

As I stated in the beginning, the high quality of OpenJDK is mainly
achieved because of the real smart committers behind it (and the companies
paying them), and the high-quality code committed and reviewed by those.
There are not many software projects that can celebrate their 25th birthday
like this. Committers write code, and use infrastructure to collaborate.
Infrastructure evolves. I've been a happy mercurial user for a long time,
and gradually moved to git and mainly github over the past years. None of
the bottlenecks I ran into have been due to github. As long as the quality
bar is not lowered, I'm ok with changes in infrastructure.

- Johan

Op di 12 nov. 2019 om 17:02 schreef <mark.reinhold at>:

> - Mark

More information about the discuss mailing list