New candidate JEP: 357: Migrate from Mercurial to Git

[Roman Kennke]

>> https://openjdk.java.net/jeps/357
> 
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
> 
> The disadvantages, off the top of my head:
>  *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;
>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;
> 
> Additionally, not addressed:
>  *) Existing hgupdater links in JBS would have to be updated, or they would break;
>  *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;
>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).
>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.
> 
> AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
> discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
> that state at the moment.

Agreed.

It seems that the very minimum requirement to reach the goals while not
disrupting workflow too much (as promised earlier elsewhere), and let
people adopt to the new git world (if it happens), would be a read-only
one-way bridge that mirrors whatever happens in new git develepment
repos to mercurial. I for one certainly wouldn't like to be forced to
juggle my workflow at a pace that I have no control over, having my own
projects, deadlines, customers, etc to meet.

But more generally, maybe we should discuss the 'if' and 'why' first,
and not the 'how'?

Roman