New candidate JEP: 369: Migrate to GitHub

[Florian Weimer]

* Andrew John Hughes:

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

*That* is a helpful property of these review tools because it removes
ambiguity of what is being proposed.  Even webrev normalizes submitted
patches, so that it is less of a problem for OpenJDK, but just the
other day, I managed to produce an empty webrev, and I've struggled
with the tool before.  So I'd gladly welcome an upgrade here.

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

That is true in general.

However, with a migration to Github specifically, you do not have a
choice: you cannot disable pull requests.  You need to do *something*
with them.  If you do not support a pull request workflow, you have to
close them and tell the would-be contributor to try again using the
appropriate process.  I can tell you from personal experience that
this can be rather annoying.  Especially with the OCA situation, I
would suggest something that guides the submitter early on, instead of
telling them that they did it incorrectly, with a delay.