New candidate JEP: 369: Migrate to GitHub

[Joe Darcy]

Hello,

A sentiment that has been expressed several times on this thread is "If 
someone is dedicated enough to the JDK, they'll just learn to use 
Mercurial." This can easily go in the other direction; if the JDK moves 
to Git on a hosting provider, "If someone is dedicated enough to the 
JDK, they'll just learn to use Git on a hosting provider." As Git is 
currently the most widely-used SCM and GitHub a common hosting provider, 
many people may have very little to learn.

As has been attested to several times on this thread, there are at least 
several experienced developers who have been put off from contributing 
to the JDK because of the SCM situation. My sense is that many 
developers feel the JDK's continued use of Mercurial is retrograde and 
that a move to Git on a hosting provider is already years overdue. I 
think postponing consideration of a migration another year, two years, 
(five years?, ten years?) would be harmful to the health of the overall 
JDK effort.

Any SCM move has the potential to be disruptive, but such a move should 
be approached with care rather than timidity.

-Joe


On 11/15/2019 2:37 AM, Mario Torre wrote:
> Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne
> <scolebourne at joda.org> ha scritto:
>> Just to note that I remain hugely supportive of this. GitHub's
>> community interaction facilities have been very positive to use from
>> my perspective, and I've never regretted moving to git or GitHub. With
>> automated testing of patches, it will represent a step change in the
>> ability to interact with the project.
> You don't need GitHub and its workflow to have have automated testing
> of patches, for instance it's nevertheless a good idea to extend the
> hotspot submit repo to cover any patch.
>
> In all those discussions we've always seen some form of "this will
> improve because X and Y" but overall those X and Y are actually
> independent from the move to GitHub and the new imposed workflow and
> never address the one and most important issue, the overhead of
> adapting to a completely new workflow and in particular that of the
> pull-request/public fork approach. I think the JEP should extensively
> prove why the change is significantly better than the status quo so
> that this change is worth, it feels to me that the situation is
> reversed here.
>
> Btw, I'll be very happy to host a discussion about this more during
> FOSDEM and have an actual confrontation, perhaps it's even a better
> idea to discuss this during the Committer's Workshop (assuming there
> will be one in February), but so far what I see is that this
> discussion is a bit stalled.
>
> In my previous email I jokingly said (and perhaps it wasn't really
> really clear I meant it like "good try Mario") to wait one or two
> years for this to settle, but I'm very convinced that we really need
> to give more time to the projects that were currently moved to GitHub
> to see if the additional hassle and the workflow change (including the
> time and resources needed to adjust the tools and the general
> ecosystem) is actually really that valuable: this JEP is premature.
>
> Cheers,
> Mario
>