New candidate JEP: 369: Migrate to GitHub

Joe Darcy joe.darcy at
Thu Nov 14 07:20:47 UTC 2019


Thanks all for the thoughtful responses thus far.

On 11/13/2019 5:24 AM, Mario Torre wrote:
> Il giorno mer 13 nov 2019 alle ore 12:42 Erik Helin
> <erik.helin at> ha scritto:
>> This does not paint the whole picture. You are probably thinking of the
>> "Conversation" tab in a GitHub pull request which is meant for *general*
>> discussion of the patch that is not attached to any particular change in
>> the patch. GitHub's own help documentation [0] states that the
>> "Conversation" tab is meant to be used for:
>>       You can comment on a pull request's Conversation tab to leave
>>       general comments, questions, or props.
>> You are right that comments in the "Conversation" tab are linearized and
>> does not support a "tree style" view of comments.
>> The good news are that the _other_ form of comments available on a
>> GitHub pull request, a so-called "review comment" or "file comment" [1],
>> does support replies in the form of a tree. These comments are filed
>> under the "Files changed" tab in a pull request.
>> Personally I think of the comments in the "Conversation" tab as replies
>> to the "00" email in a classic patch series email and the "review
>> comments" in the "Files changed" tab as replies to the "0X" emails
>> actually containing patches. Do you follow?
> Hi Erik,
> Your reply to me highlight the most important issue of all, we will
> have to re-learn all the workflow, adjust to new tools (which are not
> inherently integrated in Git but will have to be somehow configured
> and used) and get used to GitHub before we can be good citizens again.

It is certainly true that changing the JDK's SCM from Mercurial to Git 
would be at least a transitory hassle.

Despite its technical merits and ease of use, Mercurial's usage is 
plummeting, as further evidenced by losing support from BitBucket in the 
near future [1]. I don't think using an increasing niche technology for 
a cornerstone of OpenJDK infrastructure is a prudent long-term choice in 
terms of keeping Java vibrant.

The Skara project has used a diligent and careful approach to revisiting 
the JDK's SCM usage. Live mirrors of active Mercurial repos have been 
available for many months, not just jdk/jdk and the update releases but 
also amber, loom, shenandoah, tsan, etc. [2] Interested parties can 
today clone those repos and start becoming familiar with Git tooling; 
see the Skara wiki for details on getting started. [3] The Skara project 
has also verified various boundary systems can work using the Git 
mirrors; inside Oracle for over a year we've run a CI job against the 
Git mirrors alongside the CI jobs run against the Mercurial masters. JBS 
integration is in progress. These intermediate states purposefully allow 
exploration of using Git as an SCM and avoid concentrating all potential 
migration activities into only a narrow time window. As previously 
stated at OCW, the Skara team is willing to host a "Git for JDK 
Developers" talk to help ease a transition to the different SCM.

The OpenJFX project's workflows are broadly similar to those of the JDK. 
As Kevin Rushforth has shared elsewhere on this thread, OpenJFX has 
successfully moved to having their master repo on GitHub using Skara 
tooling. There is no project larger than OpenJFX with a history of 
similar workflows that can be migrated to Skara other than the JDK 
mainline or update releases.

While the JDK workflows are familiar and comfortable to many of us, IMO 
some of the details of those workflows stem from the particular tooling 
available for use by OpenJDK circa 2006 and 2007. For example, mailing 
lists were available while an externally usable bug tracker was not (for 
some time), so many discussions that might otherwise be centered on the 
bug tracker have historically occurred on OpenJDK mailing lists instead. 
In contrast, the CSR (Compatibility & Specification Review) group [4] 
was created after JBS was available and CSR reviews primarily occur 
within the facilities of the bug system rather than primarily on a 
dedicated mailing list. It would be possible to conduct CSR review on a 
mailing list, but I don't think it would be beneficial to do so.

A rephrasing and expansion of the listed goal

     "Ensure that workflows structurally similar to the existing e-mail 
and webrev based workflows are supported."


     "Provide conceptual continuity between existing workflows and new 
ones on different tooling."

I would expected continued usage of mailing lists and webrevs to occur 
alongside native usage of new capabilities of a hosted Git provider. As 
one small example, there are certain kinds of review actions "Make 
*this* edit right *here*" that are considerably streamlined with GitHub 
tooling compared to the current mailing list centered interactions. The 
possibility for improvements should be considered together with the 
possibilities of regressions. I fully expect the Skara tooling to 
continue evolving and improving as well as its user base grows.







More information about the discuss mailing list