New candidate JEP: 369: Migrate to GitHub
joe.darcy at oracle.com
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 oracle.com> 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  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" ,
>> 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 . 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.  Interested parties can
today clone those repos and start becoming familiar with Git tooling;
see the Skara wiki for details on getting started.  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 
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