New candidate JEP: 369: Migrate to GitHub
fw at deneb.enyo.de
Thu Nov 14 19:20:45 UTC 2019
* 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
*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.
More information about the discuss