New candidate JEP: 369: Migrate to GitHub

[Andrew John Hughes]

On 13/11/2019 16:21, Kevin Rushforth wrote:

snip...

> 
> To be sure, there is a bit of a learning curve moving to Git and moving
> to a pull request model where each developer has a fork of the actual
> repo, but I think that the benefits outweigh the drawbacks.
> 
> -- Kevin
> 

Each developer has a fork of the actual repo as it stands now; this is
the very nature of using a distributed version control system (DVCS).
What differs with the pull request model is that fork is made public
rather than patches being generated from it and posted. The advantage of
that is that other developers can check out the published repository
rather than attempting to recreate it by applying the patch to their own
fork.

The title of this JEP is misleading. It is not primarily about migrating
to GitHub, but about moving OpenJDK to the push request model. While the
GitHub tooling makes this *possible*, it does not make it *mandatory*.
Skimming the discussion of JEP 357, "Migrate from Mercurial to Git",
suggests that this would implicitly involve migration to GitHub as no
other hosting provision is being suggested for the git repositories
created by that JEP. Hence, I would suggest that this JEP be retitled
and the transfer of repositories to GitHub be rehoused under JEP 357.

Both changes - to using Git and to using a pull request model -
necessitate significant alterations to an OpenJDK developer's working
patterns. I would strongly suggest that the two are kept separate and
time given to adapt to the first before trying to implement the latter.
It is perfectly possible for someone to push their changes to a Git
repository rather than a Mercurial repository without having to change
the format of commit messages or the review process.

JEP-369 mentions that there is a wide range of preferred work patterns
for OpenJDK developers. I would also add that there is a wide range of
experience as well. What I see from the discussion on this thread so far
is relative contentment from those already using the push request model
on smaller projects, and concerns from those with limited or no
experience of it. The former have had the advantage of having time to
experiment with this model before it becomes intrinsic to the entire
project. I would suggest we try to do more of this rather than shift all
JDK 11 and up projects in one go. Many of us are not involved in the
projects that have experimented with this so far. A helpful next step
would be to use this model for the next update project, 14u. There is
then the opportunity for those on the JDK project to use it without
being obligated to switch to it for everything immediately.

I can see the clear desire to implement JEP-357 sooner rather than
later. JEP-296 has created a situation where the current repositories
are struggling, due to their size. This is true even in local
transactions, without factoring in network isuses, and personally I'm
relieved when my work involves 7u & 8u rather than than slower 11u+
repositories. I seem to recall that the issue of the individual jdk and
hotspot repositories already showing strain was raised at the time of
JEP-296, so we've seen this coming from some time. It worries me a
little that an entire DVCS swap is being proposed without, apparently,
any attempts to speed up Mercurial operations having being tried, but I
guess switching to git is more of a known result, and there's also a
general industry consensus around git that wasn't present when Mercurial
was selected in 2007.
I can't see the impetus for the push request model in the same way, and
it seems the switch to GitHub is being used to cloud the necessity of
such a move. As I said above, it would be much preferable to implement
git on GitHub using the existing processes and then consider such a
switch once everyone is settled, rather than attempting to combine the
two migrations.

TL;DR: switch to Git & GitHub now, but reserve this JEP for
consideration of a push request model once that switch is fully complete.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew