New candidate JEP: 357: Migrate from Mercurial to Git

[Aleksey Shipilev]

On 7/15/19 10:10 PM, Joe Darcy wrote:
> On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
>> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>>> https://openjdk.java.net/jeps/357
>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>> performing this move.

This comment of mine still stands very firmly.

>> 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;
> 
> Clearly the development processes of the projects in question would have to be updated at least
> slightly if the SCM used for the code is changed. Just on an administrative front, several months
> back as part of Skara mirrors of git conversions of Amber, Loom, Panama, etc. were put up on github:
> 
>     ...>
> These are live mirror updated within a few minutes after a push occurs to the corresponding hg repo.

You see, this is the other way around. These are read-only Git mirrors of active Mercurial repos, of
course there is no impact, we can just ignore Git mirrors exist. What JEP proposes is to switch work
to Git mirrors (and maybe have read-only Mercurial repos _tracking_ them? not clear from JEP text),
this would be non-ignorable thing. If you look carefully, your comment does not address my concern
at all.

>>   *) 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;
> 
> Yes; it is true, switching SCMs would involve a nonzero amount of time and effort to learn the new
> tool. This is true independent of the length of the release cycle. Since the proposal is to change
> to the most widely used distributed SCM, one that has extensive tooling support, there are plenty of
> learning materials available. Additionally, if there is interest, the Skara team could do a "git for
> recalcitrant hg users" online talk.

This should be in JEP text listed as the disadvantage, and it should be discussed, the migration
aids should be listed as JEP deliverables. After that, the JEP should get the buy in from the actual
people who would have to accept this change to their workflow, based on what JEP submitters agreed
to deliver.


>>   *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
>> them;
> 
> In September 2018 the JDK build was updated to work with either git or hg as the SCM, JDK-8210283.
> If there was interest, build pipelines could be created based on the existing git mirrors today.

This comment does not address my concern. Have Skara team talked to the community builders that use
hg.o.j.n as the source for their builds? Is there a buy in from them? Are the concerns of those
builders heard and mitigations planned for? This is all not clear from the JEP.


>> Additionally, not addressed:
>>   *) Existing hgupdater links in JBS would have to be updated, or they would break;
> 
> There is nothing in the JEP that requires or implies the  old hg repos need to be destroyed. I would
> recommend leaving them in place as read-only archives. Barring that, I recommend a proxy to rewrite
> the hg links into equivalent git ones. The Skara conversion process includes a map of corresponding
> hashes between the hg and git repos.

So, which one would it be? Mercural repos permanently archived, or rewrite proxy set up, or
something else? It is time to decide now: the JEP should clearly say what would be the deliverable.

>>   *) 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;
> 
> Breaking the links could be added as a non-goal of JEP. (I frequently use those links myself.)

It should be the *goal* to *not* break those links today, or set us up for breakage in future.

----

These two concerns from my original note were not mentioned in the reply at all:

 *) 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.

-- 
Thanks,
-Aleksey