Mercurial clonebundles for hg.openjdk.java.net

[Aleksey Shipilev]

On 10/03/2018 01:32 AM, mark.reinhold at oracle.com wrote:
> 2018/10/2 16:19:24 -0700, joe.darcy at oracle.com:
>> We're focusing Skara efforts on git work.
> 
> To add a little more detail ...
> 
> The version of Mercurial on hg.openjdk.java.net is old, and it doesn’t
> support the clonebundles extension, so we’d have to upgrade that.  We’d
> have to revise the code that manages the repos to take clonebundles into
> account when configuring a repository.  Finally, we’d have to figure out
> where to stash the bundles; Oracle has a CDN that we could probably use
> (the same one that hosts downloads for jdk.java.net), but dealing with
> it is, sadly, pretty awkward.

Yes, it requires work. In my experience, most solutions require work :)

My point, expanded below, is that work is desperately needed right now, without waiting for Skara to
move forward and complete. Actually, I think enabling clonebundles would be an excellent first step
under Skara, and would be well within its intent to improve developers' experience.

> My take: It’s not worth distracting the work on Skara for this.

I appreciate the hard work for moving to Git, but I think the decision to hold off clonebundles
because of Git work is ill-advised. It would make perfect sense if we were to choose where to go
from tolerable status quo to one of two better solutions, but the reality begs to differ: we are not
in the tolerable status quo.

For example, last night the CI job that checks out and builds fresh jdk-updates/jdk11u had restarted
five (!) times, all four attempts timing out after half an hour checkout from hg.openjdk.java.net,
connection terminated by remote hg. Granted, I can workaround this for myself and my team by
pointing to tarballs at https://builds.shipilev.net/workspaces/ -- but that is not the solution that
fits everyone, or that most people in OpenJDK development know. The traffic to that tarball storage
also indicates people actively search how to alleviate their problems with current hg.o.j.n.

The more worrying observation is that some disgruntled developers suggest (alas, privately to me,
after discovering the tarballs) that Oracle cannot be serious about OpenJDK if Oracle-sponsored
infrastructure is infuriatingly slow. Of course, we know that is a conspiracy theory, but we can see
the forest behind the trees here: bad developer experience transforms into bad optics, which
kneecaps our shared OpenJDK story. I have to pessimistically assume that for each developer who tell
me they are disappointed, there are tens who never receive any hand-holding to ease off their first
and bad experience with OpenJDK.

To add to this, it seemed to me that Skara project goals were to prototype and see what SCM
configurations may be better than status quo. Here is my take: clonebundles seem to work, and they
make a good stop-gap measure without intrusive changes to the rest of infrastructure and ecosystem.
It looks to me the time and effort required to enable clonebundles is understood much better and
poses much less work than transition to Git.

Bottom-line: the best is the enemy of the good. Please reconsider.

-Aleksey