New candidate JEP: 369: Migrate to GitHub

[Erik Helin]

On 11/13/19 7:31 PM, Andrew John Hughes wrote:
> 
> 
> 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.

You are missing one very important aspect here: no external source code 
hosting sites that I know of (and that would be applicable for OpenJDK) 
allows users to execute "pre-receive" hooks (also known as "pre-push" 
hooks).

Most of the things happening on our current Mercurial servers are *post* 
push actions such as sending an email to a mailing list and/or 
forwarding a commit to another repository. These are events that occur 
_after_ the pushed change has been committed to the repository on the 
server.

There is however one very important piece of code that runs _before_ the 
change is committed to the repository on the server: jcheck. Running a 
piece of code before a change is committed on a remote repository is 
known as executing a "pre-receive" or "pre-push" hook.

There is no way to allow direct pushes to a github.com (nor gitlab.com, 
bitbucket.com) repository and ensure that every commit being pushed 
passes jcheck. The good news are that using pull requests (which are 
similar to "RFR" emails, as you have also noted) allows us on in a very 
natural way to run jcheck on the commits in the pull request. I think 
the fact that we can translate a pull request to an "RFR" email thread 
shows the resemblance quite nicely.

Pull requests provides not only a logical entity that jcheck can operate 
upon, but also additional tools such as the tester bot (available 
through the `/test` command in a pull request comment).

I would also like to point that Skara enhances the "classical" pull 
request model in that the authors are the ones integrating the changes 
(compared to the maintainers integrating the changes in the "classical" 
pull request model). This is implemented through the `/integrate` 
command which is written in pull request comment, see pull request #249 
towards Skara [0] for an example.

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

We have been transitioning a few OpenJDK projetcs to GitHub on a trial 
basis. To date these include:
- Mobile
- Loom
- OpenJFX
- JMC
- Skara

It has always been the intent to transition a few projects at a time and 
learn from their experiences _before_ the main JDK repository would be 
transitioned. Ideally the jdk/jdk repository would be the very last 
repository to transition.

Thanks,
Erik

[0]: https://git.openjdk.java.net/skara/pull/249#issuecomment-552506961

> 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,
>